6 ms·

Node.js HTTP Server Security Vulnerability: Please Upgrade To 0.6.17

94 points by cleverjake 14y ago

ilaksh 14y ago
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 14y ago
  The only example of this exploit that I'm aware of is the script that Matthew sent me.
pjmlp 14y ago
C's legacy keeps spreading.
- jon6 14y ago
  Pointer arithmetic, what could go wrong?
marynixie 14y ago
I am trying to reproduce this problem with https://gist.github.com/2628868 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 14y ago
  I was only able to reproduce it sporadically. The test is a bit fiddly with the timing in the client.
aaronblohowiak 14y ago
since there are two kinds of size (size | size_), i wonder if longer, more explicit, names would have helped prevent this bug.
- recursive 14y ago
  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 14y ago
    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.
    - recursive 14y ago
      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.
    - bri3d 14y ago
      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_.
tptacek 14y ago
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.
- tedunangst 14y ago
  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.)
  - tptacek 14y ago
    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.
    - tedunangst 14y ago
      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-cgi-and-proxy-11458 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.
      - tptacek 14y ago
        No, it's nowhere nearly that complicated to exploit.
      - 14y ago

94 points by cleverjake 14y ago

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 14y ago
The only example of this exploit that I'm aware of is the script that Matthew sent me.

pjmlp 14y ago

C's legacy keeps spreading.

jon6 14y ago
Pointer arithmetic, what could go wrong?

marynixie 14y ago

I am trying to reproduce this problem with https://gist.github.com/2628868 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 14y ago
I was only able to reproduce it sporadically. The test is a bit fiddly with the timing in the client.

aaronblohowiak 14y ago

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

recursive 14y ago
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 14y ago
  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.
  - recursive 14y ago
    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.
  - bri3d 14y ago
    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_.

tptacek 14y ago

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.

tedunangst 14y ago
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.)
- tptacek 14y ago
  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.
  - tedunangst 14y ago
    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-cgi-and-proxy-11458 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.
    - tptacek 14y ago
      No, it's nowhere nearly that complicated to exploit.
    - 14y ago