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.

The public writeups have strongly implied that if I use nginx as a proxy and own all the backend servers, nothing "bad" will happen to me. Is that not the case? (I just want to understand the bug, not debate whether upgrading is the right thing.)

That's not the case at all. You can ping me privately if there's some reason you can't just patch nginx; at this point, though, you should just patch and be done with it.

Already patched. But if you could provide details (a link?) about how else one would create "specially crafted backend responses", I'd love to know more. How does an attacker make my nginx talk to their remote server (or trick my remote server into providing a specially crafted response)?

There's not a whole lot of commentary that I've found, but for instance, take these guys. "In order to exploit this vulnerability, the attacker has to be located on both sides of nginx (configured as proxy)." (http://vigilance.fr/vulnerability/nginx-memory-reading-via-c...) That about sums up my understanding as well. If that is not true, then I think the nature of the bug has been seriously misrepresented.

With approximately five minutes of conversation with Thomas I was able to write a ~30 line Ruby script which successfully compromised $A_THING_OF_IMMENSE_VALUE on a Rails app (my own, in staging) over the public Internet in a matter of seconds using no insider knowledge of that app's architecture.

Thomas is being oblique with regards to the implications of this for a reason.

Thanks. Good enough for me.

No, it's nowhere nearly that complicated to exploit.

node.js doesn't share any code with nginx

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

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.

s/corruption/information leak

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

Ah I see. Thanks I missed it there in the /deps directory, I just followed the link to a node C++ file in the commit in question.

Nginx and Node have totally separate http parsers, may be Node uses some code( like https://github.com/joyent/libuv/blob/master/include/uv-priva...) but nothing related to this issue.

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

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.

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.

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_.

> 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.

No, I do not know what the conventions are. But I do think that it's either a bad name or a bad convention. I submit as evidence that this mistake was made.

I'm not always a good judge of what adds to a conversation, but here's another attempt: Projects that have good naming conventions are likely to have fewer bugs.

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.

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

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?

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

C's legacy keeps spreading.

Pointer arithmetic, what could go wrong?