New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 1 user

Issue metadata

Status: Fixed
Owner:
OOO until July 30
Closed: Sep 2011
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug-Security

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment

Security: header injection when using embeded \0 in headerline

Reported by d0z...@gmail.com, Sep 9 2011

Issue description

VULNERABILITY DETAILS
Chrome provide undocumented character as a delimiter in HTTP response.

VERSION
Chrome Version: [13.0.782.220] + [stable]
Operating System: All

REPRODUCTION CASE
1. Run serv.pl
2. Open http://localhost:8080
3. Look at TCPDUMP, Headers, Cookies.

DETAILS:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html#sec6

After receiving and interpreting a request message, a server responds with an HTTP response message.

       Response      = Status-Line               ; Section 6.1
                       *(( general-header        ; Section 4.5
                        | response-header        ; Section 6.2
                        | entity-header ) CRLF)  ; Section 7.1
                       CRLF
                       [ message-body ]          ; Section 7.2

But \00 is also work!
Then attacker can bypass wep application filters like this: 

$location = str_replace("\r","",$location);
$location = str_replace("\n","",$location);

?location=/private-data.html%00Access-Control-Allow-Origin:%20attacker.com

Location: /private-data.html
Access-Control-Allow-Origin: attacker.com

Other browsers are not vulnerable.
 
serv.pl
787 bytes View Download
Cc: eroman@chromium.org
Labels: -Pri-0 -Area-Undefined Pri-3 Area-Internals Internals-Network-HTTP SecSeverity-Low
@eroman - Could you take a look at this or direct it to someone more appropriate?
Cc: -eroman@chromium.org wtc@chromium.org
Owner: eroman@chromium.org
Status: Assigned
I'll take a look.

As I recall, http_response_headers does in fact tokenize on \0(a design which I believe dates back to handling of winhttp responses).

It is certainly undesirable for it to interpret a \0 inside a headerline as a terminator though.

Not sure what the security severity should be set to, since technically the server is not sanitizing user inputs to lead to this situation. I'll look into a fix.
Yeah, I set it to low out of "an abundance of caution."
This is a vector for HTTP response smuggling: http://projects.webappsec.org/w/page/13246930/HTTP%20Response%20Smuggling
Yep, that's the issue. But it depends on a server not properly white-listing user data inserted into headers, which is a pretty massive danger in and of itself. So, this doesn't seem to warrant more than low severity.
Status: Started
Proposed fix: http://codereview.chromium.org/7796025
Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify Mstone-15 Merge-Approved
Status: FixUnreleased
merging to m15 makes sense or we can even leave for m16.
Labels: -Mstone-15 Mstone-16
I didn't notice any problems on Canary channel, so I merged it to M15 per approval in comment #8.

Comment 12 by d0z...@gmail.com, Sep 19 2011

Somethink else...

%0d%0d - is the same is %0d%0a%0d%0a...
also
%xx%0d%xx%0d 

It is universal bypass of PHP header() function splitting protection, which blocked %0a;

example: ?returnUrl=%0d%0di%27m%20splitting!
also: ?returnUrl=%aa%0d%aa%0di%27m%20splitting!
Labels: -Mstone-16 Mstone-15
Thanks Eric.
Regarding comment #11: technically only CRLF (i.e. 0x0D 0x0A) should be recognized as a header line terminator according to RFC 2616.

As I recall when we did early compatibility tests, we found other browsers were more permissive than the spec, and would additionally accept a naked LF (0xA) as the line separator.

For compatibility, Chrome is accepting [\r\n]+ for its line terminator, which is very permissive. We can do some more tests -- if no other major browser is supporting naked \r as a line terminator, then we could further restrict our support to \n+ or (\r\n)+.
Summary: Security: header injection when using embeded \0 in headerline
I am making this bug be specifically about embedded NULLs (the issue which was fixed).

I suggest filing a separate bug for comment #12, and we can continue our discussion there to see what we can do.

Thanks.
Labels: -merge-merged-874 Merge-Merged-874
Labels: -Merge-Approved Merge-Merged
Labels: SecImpacts-Stable
Batch update.
Labels: CVE-2011-3880

Comment 20 by cdn@chromium.org, May 15 2012

Status: Fixed
Marking old security bugs Fixed..
Project Member

Comment 21 by bugdroid1@chromium.org, Oct 13 2012

Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member

Comment 22 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Type-Security -Area-Internals -Internals-Network-HTTP -SecSeverity-Low -Mstone-15 -SecImpacts-Stable Security-Severity-Low M-15 Cr-Internals-Network-HTTP Cr-Internals Security-Impact-Stable Type-Bug-Security
Project Member

Comment 23 by bugdroid1@chromium.org, Mar 13 2013

Labels: Restrict-View-EditIssue
Project Member

Comment 24 by bugdroid1@chromium.org, Mar 13 2013

Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Labels: -Restrict-View-SecurityNotify -Restrict-View-EditIssue
Project Member

Comment 26 by bugdroid1@chromium.org, Mar 21 2013

Labels: -Security-Severity-Low Security_Severity-Low
Project Member

Comment 27 by bugdroid1@chromium.org, Mar 21 2013

Labels: -Security-Impact-Stable Security_Impact-Stable
Project Member

Comment 28 by sheriffbot@chromium.org, Oct 1 2016

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Project Member

Comment 29 by sheriffbot@chromium.org, Oct 2 2016

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: allpublic
Labels: CVE_description-submitted
Components: Internals>Network
Components: -Internals>Network>HTTP

Sign in to add a comment