
Node.js HTTP Server Security Vulnerability: Please Upgrade To 0.6.17 - cleverjake
http://blog.nodejs.org/2012/05/07/http-server-security-vulnerability-please-upgrade-to-0-6-17/
======
tptacek
This looks more or less like the same bug that hit nginx (perhaps
unsurprisingly? doesn't Node borrow nginx's HTTP parsing code?).

It's a bad bug; if you haven't updated nginx to get the patch, you should do
it. The public writeups don't do it justice.

~~~
jahewson
node.js doesn't share any code with nginx

~~~
IsaacSchlueter
That's not quite true. The http-parser library has some bits lifted from
nginx. Node itself, however, does not, and the bug is not quite the same as
the nginx bug (though they do have a lot of words in common: attacker,
request, carefully-crafted, etc. ;P

~~~
tptacek
The impact of the bug is the same, and it's an idiosyncratic kind of memory
corruption bug, which is why I thought the original flaw might have been
inherited. Thanks for clearing it up.

~~~
aaronblohowiak
s/corruption/information leak

~~~
tptacek
To my mind the exact same class of bugs, but you're not wrong to clarify. It's
a particularly bad breed of "disclosure".

------
aaronblohowiak
since there are two kinds of size (size | size_), i wonder if longer, more
explicit, names would have helped prevent this bug.

~~~
recursive
size_ is an amazingly terrible variable name, especially in a scope that also
contains size. It's a little bit surprising to me that an open source project
with node's visibility has code written that way.

~~~
javajosh
What an odd belief, that quality of variable name selection scales with open-
source project visibility! I would have thought it would scale with the
judgement of active committers.

Another odd belief is that criticizing a variable name that occurs fairly deep
in the bowels of an open-source project that you are not actively involved
with would carry any weight. Do you know what the code conventions are around
this project? Whether the underscore has some agreed-upon significance?

It's not that I'm against griping, I'm just against griping without sufficient
context. It doesn't add to the conversation.

~~~
bri3d
I think the grandparent's gripe is both valid and contributes to the
conversation: it helps remind us that when people without institutional
knowledge are encouraged to get up to speed and contribute to a project (i.e.
the whole idea of "community open source"), verbose and logical variable names
are valuable.

Asserting that size_ is always an objectively terrible name is difficult, as
yes, there might be some sort of convention around underscores. However, I
have trouble disputing that verbose, plain-English, logical variable names
help enhance code quality and reduce barriers to contribution.

I'd certainly feel much more comfortable getting up to speed with and
contributing to a code base which used more verbose and logical names than
say, size_.

~~~
aaronblohowiak
> I have trouble disputing that verbose, plain-English, logical variable names
> help enhance code quality and reduce barriers to contribution

This was the entirety of my point, but said more articulately.

------
marynixie
I am trying to reproduce this problem with <https://gist.github.com/2628868>
on node 0.6.8 and get the same result as with node 0.6.17. I use nvm to switch
between node versions. Has anyone been able to reproduce the bug? Thanks.

~~~
IsaacSchlueter
I was only able to reproduce it sporadically. The test is a bit fiddly with
the timing in the client.

------
ilaksh
Has there ever actually been a recorded case where someone has used this
against a Node.js webserver or application? And if so, what did they
accomplish?

~~~
IsaacSchlueter
The only example of this exploit that I'm aware of is the script that Matthew
sent me.

------
pjmlp
C's legacy keeps spreading.

~~~
jon6
Pointer arithmetic, what could go wrong?

