Comment by munin | Hacker News Reader

Comment by munin | Hacker News Reader

Parent Full thread

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