I'm not sure where is the security issue here. As already noted, one can just put several --proxy-header arguments, so the functionality is equivalent.
The only way this would do something unexpected (and not necessarily dangerous besides breaking the service) would be if the curl command would be used in a scenario like: (1) curl is used by some script to access some API or other URL, (2) a user can configure the script to give a specific value to an header, let's say an authentication token or similar, but the user can't directly alter the curl command (e.g. because they can only change URL and TOKEN with a web interface). Here the user would be able to add an header IF the script is not properly sanitizing the input (so the supposed security issue IMHO would be in the script), but if adding an additional header breaks security, the underlying system has a problem too...
In a very far-stretched scenario, one can possibly add two CRLFs and have the rest of the header (if any) considered by the server as data. IF the request is a POST/PUT/... request, and IF the server returns (or allows later access to) the data, and IF the attacker manipulating the supposedly-restricted single-header can see the output of the call (or retrieve the saved data), then we'd have an information disclosure issue. Would it disclose anything sensitive? Not sure, unless there's an auth token or something AFTER the header. And again, I'd rather incriminate the curl caller for not sanitizing the input if this happens.
blueflow · 9h ago
Check the man-page first. You need to know how a program is supposed to behave before you can know that an observed behavior is off-spec and warrants a bug.
robertlagrant · 7h ago
I don't understand the "This is not supposed to happen". Can someone explain?
I suppose it kind of depends. I agree with the curl team here that this is a case of garbage in/garbage out, but I can imagine this going wrong with a binary protocol like HTTP2 on the front and a text protocol like HTTP 1.1 behind a reverse proxy. The \r\n will make it to the proxy as a separate header, but will be turned into two headers on the upstream.
That said, this would be a (reverse) proxy vulnerability, not one in curl.
That is not a bug in curl, at most it's a bug in whatever gathered $UNTRUSTED_USER_INPUT.
flotzam · 7h ago
People still expect an API to reject illegal values. Calling the parameter --proxy-header (singular) could lead someone to assume that multiline strings are illegal values, even if there's a note in the docs somewhere saying otherwise.
blueflow · 6h ago
Then the people assuming random things without doing research are to blame, not curl.
flotzam · 6h ago
Apportioning blame doesn't get rid of bugs; misuse resistant APIs do.
blueflow · 6h ago
Reading docs ("research") is essential part of engineering.
Lets ask the question reversed: How did people know in the first place what kind of string they need to give to --proxy-header?
flotzam · 6h ago
> Reading docs ("research") is essential part of engineering.
Sure, but so is safety engineering. Making mechanisms more obvious to use correctly or fail safe if used incorrectly improves outcomes when flawed human beings use them. It also makes them more pleasant to use in general.
Besides, look at the man page in question. It's talking about this in terms of encoding niceties and doesn't even spell out the possibility of deliberate, let alone malicious multiline values:
"curl makes sure that each header you add/replace is sent with the proper end-of-line marker, you should thus not add that as a part of the header content: do not add newlines or carriage returns, they only mess things up for you."
That's inducing a wrong/incomplete mental model of how this parameter works.
blueflow · 6h ago
> doesn't even spell out the possibility of deliberate, ... multiline values
It does for me, as any kind of extra newlines results in a multi-line string.
> ... malicious ...
Like Daniel said, garbage in, garbage out. If you pass user inputs to curl, one should check what curl does with these values and take proper care.
robertlagrant · 6h ago
> That is not a bug in curl, at most it's a bug in whatever gathered $UNTRUSTED_USER_INPUT.
But that could just contain the bad header only, could it not?
The only way this would do something unexpected (and not necessarily dangerous besides breaking the service) would be if the curl command would be used in a scenario like: (1) curl is used by some script to access some API or other URL, (2) a user can configure the script to give a specific value to an header, let's say an authentication token or similar, but the user can't directly alter the curl command (e.g. because they can only change URL and TOKEN with a web interface). Here the user would be able to add an header IF the script is not properly sanitizing the input (so the supposed security issue IMHO would be in the script), but if adding an additional header breaks security, the underlying system has a problem too...
In a very far-stretched scenario, one can possibly add two CRLFs and have the rest of the header (if any) considered by the server as data. IF the request is a POST/PUT/... request, and IF the server returns (or allows later access to) the data, and IF the attacker manipulating the supposedly-restricted single-header can see the output of the call (or retrieve the saved data), then we'd have an information disclosure issue. Would it disclose anything sensitive? Not sure, unless there's an auth token or something AFTER the header. And again, I'd rather incriminate the curl caller for not sanitizing the input if this happens.
To me this is the same as
That said, this would be a (reverse) proxy vulnerability, not one in curl.
Lets ask the question reversed: How did people know in the first place what kind of string they need to give to --proxy-header?
Sure, but so is safety engineering. Making mechanisms more obvious to use correctly or fail safe if used incorrectly improves outcomes when flawed human beings use them. It also makes them more pleasant to use in general.
Besides, look at the man page in question. It's talking about this in terms of encoding niceties and doesn't even spell out the possibility of deliberate, let alone malicious multiline values:
"curl makes sure that each header you add/replace is sent with the proper end-of-line marker, you should thus not add that as a part of the header content: do not add newlines or carriage returns, they only mess things up for you."
That's inducing a wrong/incomplete mental model of how this parameter works.
It does for me, as any kind of extra newlines results in a multi-line string.
> ... malicious ...
Like Daniel said, garbage in, garbage out. If you pass user inputs to curl, one should check what curl does with these values and take proper care.
But that could just contain the bad header only, could it not?