Impact
What kind of vulnerability is it? Who is impacted?
A program using FoundationNetworking in swift-corelibs-foundation is potentially vulnerable to CRLF (\r\n) injection in URLRequest headers. In this vulnerability, a client can insert one or several CRLF sequences into a URLRequest header value. When that request is sent via URLSession to an HTTP server, the server may interpret the content after the CRLF as extra headers, or even a second request. For example, consider a URLRequest to http://example.com/ with the GET method. Suppose we set the URLRequest header "Foo" to the value "Bar\r\nExtra-Header: Added\r\n\r\nGET /other HTTP/1.1". When this request is sent, it will appear to the server as two requests:
GET / HTTP/1.1
Foo: Bar
Extra-Header: Added
GET /other HTTP/1.1
In this manner, the client is able to inject extra headers and craft an entirely new request to a separate path, despite only making one API call in URLSession. If a developer has total control over the request and its headers, this vulnerability may not pose a threat. However, this vulnerability escalates if un-sanitized user input is placed in header values. If so, a malicious user could inject new headers or requests to an intermediary or backend server. Developers should be especially careful to sanitize user input in this case, or upgrade their version of swift-corelibs-foundation to include the patch below.
Patches
Has the problem been patched? What versions should users upgrade to?
The problem has been patched by checking if header values contain characters such as CR and LF before setting or adding the header to the URLRequest. This patch allows header line folding consistent with the Darwin implementation, but rejects other invalid uses of CR or LF. The users should upgrade to version 5.7.3 to use this change.
Workarounds
Is there a way for users to fix or remediate the vulnerability without upgrading?
Users can prevent the vulnerability without upgrading by sanitizing header values before setting headers in a URLRequest. This would consist of rejecting any header values that contain CR or LF characters, perhaps allowing header line folding if desired.
References
Are there any links users can visit to find out more?
https://capec.mitre.org/data/definitions/105.html
For more information
If you have any questions or comments about this advisory:
Credits
Alessio Della Libera of Snyk Research Team
dellalibera Analyst
Impact
What kind of vulnerability is it? Who is impacted?
A program using FoundationNetworking in swift-corelibs-foundation is potentially vulnerable to CRLF (\r\n) injection in URLRequest headers. In this vulnerability, a client can insert one or several CRLF sequences into a URLRequest header value. When that request is sent via URLSession to an HTTP server, the server may interpret the content after the CRLF as extra headers, or even a second request. For example, consider a URLRequest to http://example.com/ with the GET method. Suppose we set the URLRequest header "Foo" to the value "Bar\r\nExtra-Header: Added\r\n\r\nGET /other HTTP/1.1". When this request is sent, it will appear to the server as two requests:
GET / HTTP/1.1
Foo: Bar
Extra-Header: Added
GET /other HTTP/1.1
In this manner, the client is able to inject extra headers and craft an entirely new request to a separate path, despite only making one API call in URLSession. If a developer has total control over the request and its headers, this vulnerability may not pose a threat. However, this vulnerability escalates if un-sanitized user input is placed in header values. If so, a malicious user could inject new headers or requests to an intermediary or backend server. Developers should be especially careful to sanitize user input in this case, or upgrade their version of swift-corelibs-foundation to include the patch below.
Patches
Has the problem been patched? What versions should users upgrade to?
The problem has been patched by checking if header values contain characters such as CR and LF before setting or adding the header to the URLRequest. This patch allows header line folding consistent with the Darwin implementation, but rejects other invalid uses of CR or LF. The users should upgrade to version 5.7.3 to use this change.
Workarounds
Is there a way for users to fix or remediate the vulnerability without upgrading?
Users can prevent the vulnerability without upgrading by sanitizing header values before setting headers in a URLRequest. This would consist of rejecting any header values that contain CR or LF characters, perhaps allowing header line folding if desired.
References
Are there any links users can visit to find out more?
https://capec.mitre.org/data/definitions/105.html
For more information
If you have any questions or comments about this advisory:
Credits
Alessio Della Libera of Snyk Research Team