http://blog.nodejs.org/2012/05/07/http-server-security-vulnerability-please-upgrade-to-0-6-17/
A few weeks ago, Matthew Daley found a security vulnerability in Node's HTTP implementation, and thankfully did the responsible thing and reported it to us via email. He explained it quite nicely, so I'll quote him here: > There is a vulnerability in node's http\_parser binding which allows > information disclosure to a remote attacker: > > 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; "size" is used whereas "size\_" 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. > > 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. > > The [attached files](https://gist.github.com/2628868) demonstrate the issue: $ ./node ~/stringptr-update-poc-server.js & [1] 11801 $ ~/stringptr-update-poc-client.py HTTP/1.1 200 OK Content-Type: text/plain Date: Wed, 18 Apr 2012 00:05:11 GMT Connection: close Transfer-Encoding: chunked 64 X header: This is private data, perhaps an HTTP request with a Cookie in it. 0 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. 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. 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 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's a good idea to upgrade anyway.) I'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.
