[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 exploit it. 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 full-disclosure post. 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.