Bug 1935978 (CVE-2020-28502) - CVE-2020-28502 nodejs-xmlhttprequest: Code injection through user input to xhr.send
Summary: CVE-2020-28502 nodejs-xmlhttprequest: Code injection through user input to xh...
Keywords:
Status: CLOSED NOTABUG
Alias: CVE-2020-28502
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
high
high
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 1935979 1935980
Blocks: 1935981
TreeView+ depends on / blocked
 
Reported: 2021-03-05 20:39 UTC by Pedro Sampaio
Modified: 2023-08-31 09:10 UTC (History)
35 users (show)

Fixed In Version: xmlhttprequest 1.7.0
Doc Type: If docs needed, set a value
Doc Text:
An arbitrary code injection vulnerability was found in nodejs-xmlhttprequest. For this vulnerability to occur, the connection must be initialized during the function call XMLHttpRequest.open to send requests synchronously using the parameter `async=False`. If the subsequent calls to xhr.send functions are with user-controllable input, this flaw allows an attacker to execute arbitrary code. If the xhr.send function is called on the server on behalf of a user, this allows execution on the Node.js server using the privileges of the Node.js process. The highest threat from this vulnerability is to confidentiality, integrity, as well as system availability.
Clone Of:
Environment:
Last Closed: 2021-10-28 01:13:59 UTC
Embargoed:


Attachments (Terms of Use)

Description Pedro Sampaio 2021-03-05 20:39:12 UTC
A flaw was found in xmlhttprequest before 1.7.0 and all versions of package xmlhttprequest-ssl. Provided requests are sent synchronously (async=False on xhr.open), malicious user input flowing into xhr.send could result in arbitrary code being injected and run.

References:

https://github.com/driverdan/node-XMLHttpRequest/blob/1.6.0/lib/XMLHttpRequest.js%23L480
https://snyk.io/vuln/SNYK-JAVA-ORGWEBJARSNPM-1082937
https://snyk.io/vuln/SNYK-JAVA-ORGWEBJARSNPM-1082938
https://snyk.io/vuln/SNYK-JS-XMLHTTPREQUEST-1082935
https://snyk.io/vuln/SNYK-JS-XMLHTTPREQUESTSSL-1082936

Comment 1 Pedro Sampaio 2021-03-05 20:39:49 UTC
Created nodejs-xmlhttprequest tracking bugs for this issue:

Affects: fedora-all [bug 1935979]


Created nodejs-xmlhttprequest-ssl tracking bugs for this issue:

Affects: fedora-32 [bug 1935980]

Comment 4 Jason Shepherd 2021-03-08 02:31:10 UTC
XMLHTTPRequest is included in Red Hat Quay as a dependency of engine.io-client, which is a development dependency and only used at build time.

Comment 7 Mark Cooper 2021-03-08 04:29:09 UTC
OpenShift Container Platform (OCP) grafana-container for 4.5 still has references to xmlhttprequest, as it is version grafana v6.5.3. However it's xmlhttprequest v1.8.0 and is not affected. 

For OpenShift ServiceMesh (OSSM) it's using grafana v6.4.3 and that is a vulnerable version of xmlhttprequest. However the only reference to it in the code is from d3-request which using it to push to jsDelivr:
https://github.com/d3/d3-request/blob/62551679e4f8a0cbce222174db8dcbcf3b0fd437/package.json#L20

Also checked the delivered container itself for markers from the xmlhttprequest source and couldn't find anything. Hence it's been marked as not affected.

Comment 13 Mark Cooper 2021-03-09 01:33:26 UTC
Statement:

While the OpenShift ServiceMesh (OSSM) grafana-container source does have a vulnerable version of the nodejs-xmlhttprequest, it does not bundle or use the library in the released product. Therefore, the container has been marked `not affected`.

For the OpenShift Container Platform (OCP), the grafana-container for OCP 4.5 is already using a non-affected version of xmlhttprequest (v1.8.0). Later versions of the container (4.6+) don't include xmlhttprequest.

For Red Hat Advanced Cluster Management for Kubernetes (RHACM), the different components using xmlhttprequest is already using a non-affected version (v1.8.0). Therefore, all supported RHACM versions have been marked `not affected`.

For Red Hat Ceph Storage (RHCS) 3 and 4 the grafana-container is already using a non-affected version of xmlhttprequest (v1.8.0).


Note You need to log in before you can comment on or make changes to this bug.