Sendmail's prescan exploit thoughts

[Alexander Cuttergo <algo () sdf lonestar org>]

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