Python socket.recvfrom_into() remote buffer overflow | Hacker News Reader

Python socket.recvfrom_into() remote buffer overflow

pastebin.com

77 pointscasca19 comments

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

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

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.

aha! apologies, I misunderstood what was going on

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.

Oh look, there's a place for this other than pastebin:

http://bugs.python.org/issue20246

Now why aren't you posting every security bug in every language to reach HN front page?

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.

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

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.

You're right, but the pastebin leaks adds "... and here's an exploit".

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

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.

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

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

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

The bug says Python 3 is affected

http://bugs.python.org/issue20246

haha, yup. I just straight up read the code wrong :)

Wow, good catch !

Reply on news.ycombinator.com