5 ms·

Python socket.recvfrom_into() remote buffer overflow

77 points by casca 13y ago

pekk 13y ago
Oh look, there's a place for this other than pastebin: http://bugs.python.org/issue20246 http://bugs.python.org/issue20246 Now why aren't you posting every security bug in every language to reach HN front page?
- anon1385 13y ago
  >Now why aren't you posting every security bug in every language to reach HN front page? Don't worry, your fellow Pythonistas ensure that every Ruby security bug reaches the front page. (I don't actually have any skin in this argument since I don't use either language but if you are going to ask such blatantly leading questions then you don't really deserve a better response.)
  - gjjgjgjgjgj 13y ago
    Even my postman finds Ruby and Rails exploits, given they are such low hanging fruit.
- JoachimSchipper 13y ago
  You're right, but the pastebin leaks adds "... and here's an exploit".
- tinco 13y ago
  Every security bug of this severity in every major language reaches the HN frontpage, especially if there's an easy proof of concept exploit for it.
- casca 13y ago
  Remotely exploitable vulnerabilities in commonly used languages and systems are not the same as "every security bug". These are important because knowing about them allows people to make a (usually) easy fix to protect themselves from something that could destroy their startup. Also, providing an exploit, rather than just the notification makes it clear how important it is to act quickly.
stuaxo 13y ago
Wow, good catch !
jzwinck 13y ago
Here is the patch, if you want to see what was actually missing to cause this bug: http://bugs.python.org/review/20246/diff/10559/Modules/socketmodule.c http://bugs.python.org/review/20246/diff/10559/Modules/socke... It appears to me that a well-written server would not be exploitable: the bug fixed here is a failure to check that the "nbytes" argument is not larger than the "buffer" argument. But nobody should have been calling this function with such erroneous arguments (ideally). Still a bad bug, but not as severe as it might sound at first.
- munin 13y ago
  well it's not that simple, because the 'nbytes' parameter to recvfrom_into is optional and you could infer as a programmer that it will read up to the size of your buffer, since your buffer has a size attribute attached to it. I originally thought that this wouldn't be a big deal because using recvfrom_into is annoying, you have to make a mutable buffer object and the most immediate way I found to do that involved ctypes, which is scary. However, on perusal a bunch of code hosted on github uses recvfrom_into in vulnerable ways, so that's pretty exciting. edit: I was mistaken, see below
  - saghul 13y ago
    recvfrom_into is meant to be used with bytearrays, which can give you a performance boost by avoiding one extra copy of the received data. You don't need ctypes to use it.
  - jzwinck 13y ago
    You're right: nbytes is optional. That means it is even less likely that a call to recvfrom_into will be exploitable. That's because the default maximum receive size is taken as the size of the buffer if nbytes is zero/unset. See the comment in the existing code right above the patch: /* If nbytes was not specified, use the buffer's length */ So it still seems to me that in order to be exploitable an application would need to specify a "wrong" value for nbytes, which after the patch would raise an exception. It's not a case where such code should work and instead overflows.
cool-RR 13y ago
I'd really like to know whether it means my Django apps are now vulnerable.
- nteon 13y ago
  I don't think so. I don't see any direct calls to recvfrom_into in Django, and it seems little used. It is more likely to be called with a UDP listener - with TCP sockets there isn't usually a need to use recvfrom (which returns the address of the sender, too).
nteon 13y ago
nicely, it seems that the python3 version of socketmodule doesn't use these on-stack Py_buffer objects, so wasn't affected.
- bobbyi_settv 13y ago
  The bug says Python 3 is affected http://bugs.python.org/issue20246 http://bugs.python.org/issue20246
  - nteon 13y ago
    haha, yup. I just straight up read the code wrong :)
chair6 13y ago
The original bug report said "very highly unlikely it's technically remotely exploitable", but it seems that may not be the case. "Working with the exploit, its trivial to get a working remote exploit to work, below is a simple rewritten RCE from the exploit PoC": https://www.trustedsec.com/february-2014/python-remote-code-execution-socket-recvfrom_into/ https://www.trustedsec.com/february-2014/python-remote-code-...
- makomk 13y ago
  It's only remotely exploitable in Python applications that use socket.recvfrom_into in a particular, unsafe way. I'm not sure how many are out there in practice.
- teddyh 13y ago
  You are reading it wrong. The original bug report said “I will attach patches for 3.4 and 2.7, I'm not familiar with the backporting procedure to go further but all versions since 2.5 have this bug and while very highly unlikely it's technically remotely exploitable.” So if one were to insert commas in the appropriate places, it becomes “and, while very highly unlikely, it's technically remotely exploitable.”. So the original bug report did concede that, while the bug itself is very unlikely, the bug is remotely exploitable.
pg_is_a_butt 13y ago
back to using PHP. python is full of bugs and bloat.

77 points by casca 13y ago

pekk 13y ago

Oh look, there's a place for this other than pastebin: http://bugs.python.org/issue20246 http://bugs.python.org/issue20246 Now why aren't you posting every security bug in every language to reach HN front page?

anon1385 13y ago
>Now why aren't you posting every security bug in every language to reach HN front page? Don't worry, your fellow Pythonistas ensure that every Ruby security bug reaches the front page. (I don't actually have any skin in this argument since I don't use either language but if you are going to ask such blatantly leading questions then you don't really deserve a better response.)
- gjjgjgjgjgj 13y ago
  Even my postman finds Ruby and Rails exploits, given they are such low hanging fruit.
JoachimSchipper 13y ago
You're right, but the pastebin leaks adds "... and here's an exploit".
tinco 13y ago
Every security bug of this severity in every major language reaches the HN frontpage, especially if there's an easy proof of concept exploit for it.
casca 13y ago
Remotely exploitable vulnerabilities in commonly used languages and systems are not the same as "every security bug". These are important because knowing about them allows people to make a (usually) easy fix to protect themselves from something that could destroy their startup. Also, providing an exploit, rather than just the notification makes it clear how important it is to act quickly.

stuaxo 13y ago

Wow, good catch !

jzwinck 13y ago

Here is the patch, if you want to see what was actually missing to cause this bug: http://bugs.python.org/review/20246/diff/10559/Modules/socketmodule.c http://bugs.python.org/review/20246/diff/10559/Modules/socke... It appears to me that a well-written server would not be exploitable: the bug fixed here is a failure to check that the "nbytes" argument is not larger than the "buffer" argument. But nobody should have been calling this function with such erroneous arguments (ideally). Still a bad bug, but not as severe as it might sound at first.

munin 13y ago
well it's not that simple, because the 'nbytes' parameter to recvfrom_into is optional and you could infer as a programmer that it will read up to the size of your buffer, since your buffer has a size attribute attached to it. I originally thought that this wouldn't be a big deal because using recvfrom_into is annoying, you have to make a mutable buffer object and the most immediate way I found to do that involved ctypes, which is scary. However, on perusal a bunch of code hosted on github uses recvfrom_into in vulnerable ways, so that's pretty exciting. edit: I was mistaken, see below
- saghul 13y ago
  recvfrom_into is meant to be used with bytearrays, which can give you a performance boost by avoiding one extra copy of the received data. You don't need ctypes to use it.
- jzwinck 13y ago
  You're right: nbytes is optional. That means it is even less likely that a call to recvfrom_into will be exploitable. That's because the default maximum receive size is taken as the size of the buffer if nbytes is zero/unset. See the comment in the existing code right above the patch: /* If nbytes was not specified, use the buffer's length */ So it still seems to me that in order to be exploitable an application would need to specify a "wrong" value for nbytes, which after the patch would raise an exception. It's not a case where such code should work and instead overflows.

cool-RR 13y ago

I'd really like to know whether it means my Django apps are now vulnerable.

nteon 13y ago
I don't think so. I don't see any direct calls to recvfrom_into in Django, and it seems little used. It is more likely to be called with a UDP listener - with TCP sockets there isn't usually a need to use recvfrom (which returns the address of the sender, too).

nteon 13y ago

nicely, it seems that the python3 version of socketmodule doesn't use these on-stack Py_buffer objects, so wasn't affected.

bobbyi_settv 13y ago
The bug says Python 3 is affected http://bugs.python.org/issue20246 http://bugs.python.org/issue20246
- nteon 13y ago
  haha, yup. I just straight up read the code wrong :)

chair6 13y ago

The original bug report said "very highly unlikely it's technically remotely exploitable", but it seems that may not be the case. "Working with the exploit, its trivial to get a working remote exploit to work, below is a simple rewritten RCE from the exploit PoC": https://www.trustedsec.com/february-2014/python-remote-code-execution-socket-recvfrom_into/ https://www.trustedsec.com/february-2014/python-remote-code-...

makomk 13y ago
It's only remotely exploitable in Python applications that use socket.recvfrom_into in a particular, unsafe way. I'm not sure how many are out there in practice.
teddyh 13y ago
You are reading it wrong. The original bug report said “I will attach patches for 3.4 and 2.7, I'm not familiar with the backporting procedure to go further but all versions since 2.5 have this bug and while very highly unlikely it's technically remotely exploitable.” So if one were to insert commas in the appropriate places, it becomes “and, while very highly unlikely, it's technically remotely exploitable.”. So the original bug report did concede that, while the bug itself is very unlikely, the bug is remotely exploitable.

pg_is_a_butt 13y ago

back to using PHP. python is full of bugs and bloat.