4 ms·
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 y
by munin 13y ago
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
- saghul 13y agorecvfrom_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.
- jzwinck 13y agoYou'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 13y agoaha! apologies, I misunderstood what was going on
- deleted 13y ago[deleted]