I'm assuming this affects 0.4.x as well. Yes we're still using it :( Yes we plan to upgrade soon :)
:Marco On Monday, May 7, 2012 10:09:47 AM UTC-7, Isaac Schlueter wrote: > > > 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. >
