pop_msg in debian/qpopper: core, but no exploit

herpWILDSAU.IDV-EDU.UNI-LINZ.AC.AT

• Messages sorted by: [ date ][ thread ][ subject ][ author ]
• Next message: Aleph One: "Alert: ASP vulnerability with Alternate Data Streams"
• Previous message: nicholas harteau: "Re: Sun libnsl lameness"

dear listmembers,

I was curious that debian-popper-2.2 seemed immune to the buffer overflow
in pop_msg(), and I think I've found the reason why. It's not the
function which is handling the overflow correctly, but vsprint(), which,
allthough it *does* overflow the buffer, it does not overflow it far enough
to overwrite the return address as intended.
vsprint() will overflow the buffer and the other stack-variables *and*
even the return adress, but 1) not very much further than that (regardless
of your buffer size) and 2) will only partially overwrite the return
address with the buffer. popper/debian will, however, still coredump.

e.g.: 2k overflow buffer, filled with 0x90919293

pop_msg()
 804ccb0:       55              pushl  %ebp
 804ccb1:       89 e5           movl   %esp,%ebp

esp            0xbfffef00       0xbfffef00

after vsprintf:
(gdb) x/x 0xbfffeefc
0xbfffeefc <__ypbindlist+2146652752>:   0x93909192
0xbfffef00 <__ypbindlist+2146652756>:   0x22409192
                                          ^^^^
0xbfffef04 <__ypbindlist+2146652760>:   0xbfff002e
                                              ^^^^

so you can only overwrite the last 2 byte of the return address,
specifying an offset of 64k with 0x2240XXXX, an address not accessible.
the 40222e00 sequence is the end of the "-ERR Unknown..." string: ".

so it seems, that vsprintf() under debian has some kind of boundary check,
and allthough it will still corrupt the return address, but render any
attempt to overwrite to a specific value useless.
can anyone confirm that ?

regards,
h.rosmanith

• Next message: Aleph One: "Alert: ASP vulnerability with Alternate Data Streams"
• Previous message: nicholas harteau: "Re: Sun libnsl lameness"