Florian Weimer writes: > bugzilla@redhat.com writes: > > > Updated fetchmail packages are available for Red Hat Linux 6.2, 7, 7.1, > > 7.2, and 7.3 which close a remotely-exploitable vulnerability in unpatched > > versions of fetchmail prior to 5.9.10. > > It appears that this vulnerability is caused by some alloca() > implementations which do not return zero if the caller requests more > memory than which is available. This is hard to do. Since alloca memory is on the stack, you have to know where the bottom of the stack is. You can get the stack size from getrlimit(2), but now you need to know where the top is. On Linux at least, this is a compile-time kernel constant whose value depends on such things as the amount of memory in the machine. I'm not aware of any good way to query it. Furthermore, having to do a getrlimit(2) on each alloca call tends to defeat the purpose of alloca, which is mainly to be very fast. On many systems it's a single instruction. But if you throw in the system call, then you might as well call `malloc' instead. > Red Hat's patch does not address the root of the problem by fixing > alloca() (a problem which might be of more generic nature and could > well be present in other software as well), but it bounds the > requested memory by something which appears to be a rather arbitrary > constant. Is there more information about the vulnerability somewhere, or maybe an exploit? I see the bug, but I'm not sure I understand how it's exploitable, or how the given patch fixes it. -- Nate Eldredge neldredge@hmc.edu
