Hacker News Reader

Comment by jzwinck | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com