

Python socket.recvfrom_into() remote buffer overflow - casca
http://pastebin.com/raw.php?i=GHXSmNEg

======
jzwinck
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...](http://bugs.python.org/review/20246/diff/10559/Modules/socketmodule.c)

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

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

~~~
munin
aha! apologies, I misunderstood what was going on

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

------
chair6
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-...](https://www.trustedsec.com/february-2014/python-remote-code-
execution-socket-recvfrom_into/)

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

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

~~~
nteon
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
nicely, it seems that the python3 version of socketmodule doesn't use these
on-stack Py_buffer objects, so wasn't affected.

~~~
bobbyi_settv
The bug says Python 3 is affected

[http://bugs.python.org/issue20246](http://bugs.python.org/issue20246)

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

------
stuaxo
Wow, good catch !

