Skip to content

Commit b1c8f45

Browse files
nschonniMylesBorins
authored andcommitted
fix: Use Markdown blockquotes
Converte the resto of http-server-security-vulnerability-please-upgrade-to-0-6-17.md to pure MD at the same time
1 parent 607934a commit b1c8f45

2 files changed

Lines changed: 41 additions & 40 deletions

File tree

.markdownlint.json

Lines changed: 0 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -16,7 +16,6 @@
1616
"allowed_elements": [
1717
"a",
1818
"br",
19-
"blockquote",
2019
"hr",
2120
"h1", "h2", "h3", "h4",
2221
"figure", "figcaption", "img",

locale/en/blog/vulnerability/http-server-security-vulnerability-please-upgrade-to-0-6-17.md

Lines changed: 41 additions & 39 deletions
Original file line numberDiff line numberDiff line change
@@ -7,42 +7,44 @@ category: vulnerability
77
slug: http-server-security-vulnerability-please-upgrade-to-0-6-17
88
layout: blog-post.hbs
99
---
10-
11-
<h2>tl;dr</h2>
12-
13-
<ul><li><p>A carefully crafted attack request can cause the contents of the HTTP parser's buffer to be appended to the attacking request's header, making it appear to come from the attacker. Since it is generally safe to echo back contents of a request, this can allow an attacker to get an otherwise correctly designed server to divulge information about other requests. It is theoretically possible that it could enable header-spoofing attacks, though such an attack has not been demonstrated.</li>
14-
<li>Versions affected: All versions of the 0.5/0.6 branch prior to 0.6.17, and all versions of the 0.7 branch prior to 0.7.8. Versions in the 0.4 branch are not affected.</li>
15-
<li>Fix: Upgrade to <a href="http://blog.nodejs.org/2012/05/04/version-0-6-17-stable/">v0.6.17</a>, or apply the fix in <a href="https://github.com/joyent/node/commit/c9a231d">c9a231d</a> to your system.</li></ul>
16-
17-
<h2>Details</h2>
18-
19-
<p>A few weeks ago, Matthew Daley found a security vulnerability in Node&#39;s HTTP implementation, and thankfully did the responsible thing and reported it to us via email. He explained it quite well, so I'll quote him here:</p>
20-
<blockquote>
21-
<p>There is a vulnerability in node&#39;s `http_parser` binding which allows information disclosure to a remote attacker:
22-
23-
</p>
24-
<p>In node::StringPtr::Update, an attempt is made at an optimization on certain inputs (`node_http_parser.cc`, line 151). The intent is that if the current string pointer plus the current string size is equal to the incoming string pointer, the current string size is just increased to match, as the incoming string lies just beyond the current string pointer. However, the check to see whether or not this can be done is incorrect; &quot;size&quot; is used whereas &quot;size_&quot; should be used. Therefore, an attacker can call Update with a string of certain length and cause the current string to have other data appended to it. In the case of HTTP being parsed out of incoming socket data, this can be incoming data from other sockets.
25-
26-
</p>
27-
<p>Normally node::StringPtr::Save, which is called after each execution of `http_parser`, would stop this from being exploitable as it converts strings to non-optimizable heap-based strings. However, this is not done to 0-length strings. An attacker can therefore exploit the mistake by making Update set a 0-length string, and then Update past its boundary, so long as it is done in one `http_parser` execution. This can be done with an HTTP header with empty value, followed by a continuation with a value of certain length.
28-
29-
</p>
30-
<p>The <a href="https://gist.github.com/2628868">attached files</a> demonstrate the issue: </p>
31-
<pre><code>$ ./node ~/stringptr-update-poc-server.js &amp;
32-
[1] 11801
33-
$ ~/stringptr-update-poc-client.py
34-
HTTP/1.1 200 OK
35-
Content-Type: text/plain
36-
Date: Wed, 18 Apr 2012 00:05:11 GMT
37-
Connection: close
38-
Transfer-Encoding: chunked
39-
40-
64
41-
X header:
42-
This is private data, perhaps an HTTP request with a Cookie in it.
43-
0</code></pre>
44-
</blockquote>
45-
<p>The fix landed on <a href="https://github.com/joyent/node/commit/7b3fb22">7b3fb22</a> and <a href="https://github.com/joyent/node/commit/c9a231d">c9a231d</a>, for master and v0.6, respectively. The innocuous commit message does not give away the security implications, precisely because we wanted to get a fix out before making a big deal about it. </p>
46-
<p>The first releases with the fix are v0.7.8 and 0.6.17. So now is a good time to make a big deal about it. </p>
47-
<p>If you are using node version 0.6 in production, please upgrade to at least <a href="http://blog.nodejs.org/2012/05/04/version-0-6-17-stable/">v0.6.17</a>, or at least apply the fix in <a href="https://github.com/joyent/node/commit/c9a231d">c9a231d</a> to your system. (Version 0.6.17 also fixes some other important bugs, and is without doubt the most stable release of Node 0.6 to date, so it&#39;s a good idea to upgrade anyway.) </p>
48-
<p>I&#39;m extremely grateful that Matthew took the time to report the problem to us with such an elegant explanation, and in such a way that we had a reasonable amount of time to fix the issue before making it public. </p>
10+
## tl;dr
11+
12+
- A carefully crafted attack request can cause the contents of the HTTP parser's buffer to be appended to the attacking request's header, making it appear to come from the attacker. Since it is generally safe to echo back contents of a request, this can allow an attacker to get an otherwise correctly designed server to divulge information about other requests. It is theoretically possible that it could enable header-spoofing attacks, though such an attack has not been demonstrated.
13+
- Versions affected: All versions of the 0.5/0.6 branch prior to 0.6.17, and all versions of the 0.7 branch prior to 0.7.8. Versions in the 0.4 branch are not affected.
14+
- Fix: Upgrade to [v0.6.17](http://blog.nodejs.org/2012/05/04/version-0-6-17-stable/, or apply the fix in [c9a231d](https://github.com/joyent/node/commit/c9a231d) to your system.
15+
16+
## Details
17+
18+
A few weeks ago, Matthew Daley found a security vulnerability in Node&#39;s HTTP implementation, and thankfully did the responsible thing and reported it to us via email. He explained it quite well, so I'll quote him here:
19+
20+
> There is a vulnerability in node&#39;s `http_parser` binding which allows information disclosure to a remote attacker:
21+
>
22+
> In node::StringPtr::Update, an attempt is made at an optimization on certain inputs (`node_http_parser.cc`, line 151). The intent is that if the current string pointer plus the current string size is equal to the incoming string pointer, the current string size is just increased to match, as the incoming string lies just beyond the current string pointer. However, the check to see whether or not this can be done is incorrect; &quot;size&quot; is used whereas &quot;size_&quot; should be used. Therefore, an attacker can call Update with a string of certain length and cause the current string to have other data appended to it. In the case of HTTP being parsed out of incoming socket data, this can be incoming data from other sockets.
23+
>
24+
> Normally node::StringPtr::Save, which is called after each execution of `http_parser`, would stop this from being exploitable as it converts strings to non-optimizable heap-based strings. However, this is not done to 0-length strings. An attacker can therefore exploit the mistake by making Update set a 0-length string, and then Update past its boundary, so long as it is done in one `http_parser` execution. This can be done with an HTTP header with empty value, followed by a continuation with a value of certain length.
25+
>
26+
> The [attached files](https://gist.github.com/2628868) demonstrate the issue:
27+
>
28+
> ```
29+
> $ ./node ~/stringptr-update-poc-server.js &amp;
30+
> [1] 11801
31+
> $ ~/stringptr-update-poc-client.py
32+
> HTTP/1.1 200 OK
33+
> Content-Type: text/plain
34+
> Date: Wed, 18 Apr 2012 00:05:11 GMT
35+
> Connection: close
36+
> Transfer-Encoding: chunked
37+
>
38+
> 64
39+
> X header:
40+
> This is private data, perhaps an HTTP request with a Cookie in it.
41+
> 0
42+
> ```
43+
44+
The fix landed on [7b3fb22](https://github.com/joyent/node/commit/7b3fb22) and [c9a231d](https://github.com/joyent/node/commit/c9a231d), for master and v0.6, respectively. The innocuous commit message does not give away the security implications, precisely because we wanted to get a fix out before making a big deal about it.
45+
46+
The first releases with the fix are v0.7.8 and 0.6.17. So now is a good time to make a big deal about it.
47+
48+
If you are using node version 0.6 in production, please upgrade to at least [v0.6.17](http://blog.nodejs.org/2012/05/04/version-0-6-17-stable/), or at least apply the fix in [c9a231d](https://github.com/joyent/node/commit/c9a231d) to your system. (Version 0.6.17 also fixes some other important bugs, and is without doubt the most stable release of Node 0.6 to date, so it&#39;s a good idea to upgrade anyway.)
49+
50+
I&#39;m extremely grateful that Matthew took the time to report the problem to us with such an elegant explanation, and in such a way that we had a reasonable amount of time to fix the issue before making it public.

0 commit comments

Comments
 (0)