New issue
Advanced search Search tips

Issue 669012 link

Starred by 1 user
Status: WontFix
Owner: ----
Closed: Nov 2016
Cc:
mmenke@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: ----
Type: Bug-Security



Sign in to add a comment

Status-line Script Execution via HTTP/0.9

Reported by mohdsham...@gmail.com, Nov 28 2016 
VULNERABILITY DETAILS
Javascript Execution at Status-Line

VERSION
Chrome Version: all
Operating System: Windows and Android

REPRODUCTION CASE
Status-line in HTTP response(HTTP/1.1) is to be manipulated in order to execute javascript on client browser. python script is attached which listens on port 80 and responds with a script on 404 code. Run the python code and visit the HTTP page on the IP via Chrome(Desktop, android)

In order to easily reproduce this , intercept the response from any webserver and inject <script>alert(9)</script> at "HTTP/1.1", so the response would look like "<script>alert(9)</script> 200 OK". Let this response hit the chrome browser. Script will be execution.

RFC 7230 section 2.1 talks about status line. Chrome does not appear to handle malformed status-line it correctly.
This is undesirable behavior of the browser. Malformed response should be discarded or sanitized and then loaded a body.
An attacker can easily setup a server and deliver any complex script to compromise client security. This might also be able to bypass IPS which look for HTML context.

Thanks and regards,
Shameem
pws.py
5.6 KB View Download

Comment 1 by elawrence@chromium.org, Nov 28 2016

Components: Blink>Network
Status: Untriaged (was: Unconfirmed)
Summary: Status-line Script Execution in Chrome 54 (was: Status-line Script Execution in Chrome)
I'm not able to reproduce this with Chrome 57. Attempting repro, Chrome shows the expected error page:

"This page isn’t working

localhost sent an invalid response.
ERR_INVALID_HTTP_RESPONSE"

I can think of two ways in which Chrome could execute script served in a manner similar to that described:

1> The server serves a previous response without a proper Content-Length declaration, such that a proxy or other intermediary serves the script code from a second response at the end of the body of the first response. Chrome would see this as a continuation of the first response and would execute the script as a part of the previous page. This would be considered a bug in the server.

2> As the response is not formatted properly, the response is deemed to be a HTTP/0.9 response, which is a type that does not contain HTTP response headers. As a consequence, the response is treated as a HTML document and script is executed. Addressing incorrect support of HTTP/0.9 is tracked by  Issue 624462 .

Indeed in Chrome 54, I am able to reproduce in 54.0.2840.99. If you open the Developer Tools, you will see that the protocol is marked "HTTP/0.9" indicating that this is a variant of  issue 624462 .

Comment 2 Deleted

Comment 3 by elawrence@chromium.org, Nov 28 2016

Cc: mmenke@chromium.org
Summary: Status-line Script Execution via HTTP/0.9 (was: Status-line Script Execution in Chrome 54 via HTTP/0.9)
Clarification: This does repro in Chrome 57 as well, but only on port 80. That's because commit a7da6da864dce77fe1c931653635c3ac757219cb limits HTTP/0.9 usage to the default port.

Generally speaking, I think we'd consider this a server bug, but it is one argument in favor of making the HTTP/0.9 restrictions even tighter.

Comment 4 by mohdsham...@gmail.com, Nov 29 2016 

My apologies for not mentioning versions. Let me correct this. On desktop i downloaded chrome and the version is 54.0.2840.99 m. And on android the version is 46.0.2490.76, and then updated the chrome on android to 54.0.2840.85. They all are affected.

Thanks,
Shameem

Comment 5 by mmenke@chromium.org, Nov 29 2016

Status: WontFix (was: Untriaged)
Not a bug.  Neither HTTP/0.9 support nor MIME sniffing are bugs, much as we'd like to get rid of them.
Project Member

Comment 6 by sheriffbot@chromium.org, Mar 7 2017

Labels: -Restrict-View-SecurityTeam allpublic
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
►

Sign in to add a comment