In Vega before version 5.17.3 there is an XSS vulnerability in Vega expressions. Through a specially crafted Vega expression, an attacker could execute arbitrary javascript on a victim's machine. This is fixed in version 5.17.3 References: https://github.com/vega/vega/issues/3018 https://github.com/vega/vega/pull/3019 https://github.com/vega/vega/releases/tag/v5.17.3 https://github.com/vega/vega/security/advisories/GHSA-r2qc-w64x-6j54 https://www.npmjs.com/package/vega
Upstream fix: https://github.com/vega/vega/pull/3019
External References: https://github.com/advisories/GHSA-r2qc-w64x-6j54 https://discuss.elastic.co/t/elastic-stack-7-11-0-and-6-8-14-security-update/263915
Mitigation: For Kibana which does contain the dependency vega, it is possible to turn of vega visualizations with `vega.enabled: false` in the kibana.yml
No luck in replicating on the openshift4/ose-logging-kibana6. Can define the transform and filter attributes, but no XSS occurs. Could be due to variations in the default spec versions, or more likely the encoding that Kibana puts on the text passed into vega. I'm fairly confident that with enough time one would be able to find the appropriate values/encoding. However, keeping the bug for OpenShift at Moderate due to the following: - The visualizations aren't there by default and to describe a created visualization (one created by an end user), it would require some privileged information such a logging into the instance. For example: "...app/kibana?security_tenant=private#/visualize/edit/04260fa0-6f42-11eb-a00e-0bb6123cb0c3?embed=true&..." The attacker would need to know the visulization id 04260fa0-6f42-11eb-a00e-0bb6123cb0c3. - The visualization must be created first to use it in a reflected XSS manner, otherwise the user receives "Could not locate that visualization..." - If shared and embded into an iframe for example, through "share/embded code", then there is a potential to then insert code to execute into the embded url. But again, the visualization would have to be shared publicly first. - If used in a stored XSS way, then the attacker would still need privileges to store the XSS in the first place.
When Kibana is packaged as an rpm in OpenShift 3.11 and OpenShift 4.4, it is version 5.6.16 and does not include the vega visualizations (added in Kibana 6.2 https://elastic.co/blog/custom-vega-visualizations-in-kibana)
Statement: In OpenShift Container Platform 4 (OCP) the openshift4/ose-logging-kibana6 container does package a vulnerable version of the vega library. However, for an attacker to successfully perform a reflected XSS attack an existing visualization must already exist and the details known to the attacker, as the visualization ID must be referenced. Given this and to perform a stored XSS attack higher privileges are required, the impact has been set to Moderate.
closing old flaw bug