[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
question about the new sendmail prescan bug
hi all, i'm new here, so please forgive me if i don't follow any of the
conventions of this list.
i've been looking at the new sendmail bug but can't find a way to
from the patch released, i noticed that if a token is too long (256
chars), prescan() will return with delimptr pointing to an address one
beyond the end of addr buffer. then the next time parseaddr() gets
called (from a loop in sendtolist()), it'll be processing something
wild. chances are prescan call will return with a non-NULL pvp, and this
will make invalidaddr() be called, and a '\0' will be written to the
address pointed by delimptr. if this address is part of local variable
bufp in sendtolist(), we have the exploit mentioned in Michal Zalewski's
looking at the sendtolist() code, bufp seems to reside in an address
following buf, and the way described above seems to work. but when i
gdb'ed sendmail compiled with the default -O2 switch, i found buf is at
the bottom of the stack, writting somthing beyond its end won't change
the value of bufp.
btw, i don't quite understand how local variables are organized on
stack, eg. how paddings/alignments apply, when the -Ox switch is on.
thanks for any response and best regards.