Hi, I peeked a bit at the sendmail sources trying to figure out how to exploit the prescan() vulnerability, especially remotely. I haven't found a simple method - perhaps someone else will share her/his findings. The only way to fool prescan() checks seems to be to pass to it a string "\\\377\\\377\\\377\\\377....", that is, backslash followed by character 255. Notice that this string can be in the message headers, as well in the message body (in the mime headers in the latter case). Prescan will put as many slashes to the output buffer as we wish. Therefore, as the pvpbuf argument passed to prescan seems to be always on the stack, on little endian machines, we can overwrite: 1) pointer stack variables (if there are any), saved ebp and saved eip with values 0x5c5c5c5c or 0x005c5c5c (trailing 0 is appended by prescan()). In case of local exploit, we can use TOP_PAD_ env variable (does it still work ? It used to be MALLOC_TOP_PAD ?) to make 0x5c5c5c5c be a valid pointer. But I want a remote exploit. 2) we can overwrite the least byte of saved base pointer with 0 (see klog article in phrack 55; he was not the first to publicly document the technique though ;) ). But then the overwritten saved base pointer would point within pvpbuf, which contains only backslashes, which is not useful. 3) we can overwrite two least bytes of saved base pointer with 0x005c. Thus saved base pointer could point beyond pvpbuf. Unfortunately, pvpbuf is always the last variable on the local stack frame, so the space below is uninitialized. The only execution flow which seems exploitable is: a) call some function which puts on the stack ca 64 KB of user controllable data b) later call prescan() Has anyone found an appropriate flow ? Anyway, in a dynamic, remote environment, this looks like a very fragile method. Thoughts, anyone ? peace, Algo
This archive was generated by hypermail 2b30 : Thu Apr 03 2003 - 09:35:13 PST