>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.)
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.
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.
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.
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.
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.
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).
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.
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.
22 comments
[ 4.4 ms ] story [ 24.1 ms ] threadhttp://bugs.python.org/issue20246
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.)
Also, providing an exploit, rather than just the notification makes it clear how important it is to act quickly.
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.
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
http://bugs.python.org/issue20246
"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-...
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.
python is full of bugs and bloat.