full-disclosure - Lame crash in qmail-smtpd and NO memory overwrite according to gdb

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <86fzebidwt.fsf@home.nest.cx>
From: greg-fulldisclosure at y2004.nest.cx (Gregory Steuck)
Subject: Lame crash in qmail-smtpd and NO memory overwrite according to gdb

Hi Georgi,

    Georgi> Description: Actually there are two different problems: a)
    Georgi> It is possible to crash qmail-smtpd 1.03 from remote with a
    Georgi> long SMTP session. The crash is not global, it affects only
    Georgi> the current SMTP session.

This seems to be a genuine integer overflow. I get the same SIGSEGV.
This problem should be fixed by changing pos type to unsigned int.

I do not see this being exploitable though. It is yet another denial of
service and to trigger it the client will need to send 2GB of data.

    Georgi> b) If gdb is to be believed, it is possible to overwrite
    Georgi> memory in qmail-smtpd 1.03 from remote with a long SMTP
    Georgi> session.

This is likely false.

    Georgi> Program received signal SIGPIPE, Broken pipe.

This is due to qmail-queue dying. Likely you do not have 2G available in
/var/qmail/queue and it is running out of space.

    Georgi> 0x40102748 in write () from /lib/libc.so.6
    Georgi> #0  0x40102748 in write () from /lib/libc.so.6
    Georgi> #1  0x00000400 in ?? ()
    Georgi> #2  0x0804bb81 in substdio_flush (s=0x804eae4) at substdo.c:35
    Georgi> #3  0x0804bc1e in substdio_put (s=0x4, buf=0xbffffd5b "g\030", len=134540004)
    Georgi>     at substdo.c:64 <-- wtf is this len ??
    Georgi> #4  0x0804ab58 in qmail_put (qq=0x804eac0, s=0xbffffd5b "g\030", len=1)
    Georgi>     at qmail.c:56
    Georgi> #5  0x08049309 in put (ch=0xbffffd5b "g\030") at qmail-smtpd.c:290
    Georgi> #6  0x0804941d in blast (hops=0xbffffd8c) at qmail-smtpd.c:360

What sources did you use for your experiments? Your line numbers do not
match mine (http://cr.yp.to/software/qmail-1.03.tar.gz)
SHA1 (qmail-1.03.tar.gz) = 18fb960481291a0503e93a94df3f6094edb7f27a

Line 360 is in acceptmessage() and not in blast().

    Georgi> #7  0x08049669 in smtp_data () at qmail-smtpd.c:393
    Georgi> #8  0x08049a66 in commands (ss=0x804d09c, c=0x804d0c0) at commands.c:37
    Georgi> #9  0x080497c5 in main () at qmail-smtpd.c:430
    Georgi> #10 0x40042917 in __libc_start_main () from /lib/libc.so.6
    Georgi> (gdb) frame 2
    Georgi> #2  0x0804bb81 in substdio_flush (s=0x804eae4) at substdo.c:35
    Georgi> 35        return allwrite(s->op,s->fd,s->x,p);
    Georgi> (gdb) p *s
    Georgi> $1 = {x = 0x67676767 "", p = 1734829927, n = 1734829927, fd = 1734829927,
    Georgi>   op = 0x67676767}

    Georgi> When you get s->op=0x67676767 it is not good :)

I do not get such invalid s->op values on OpenBSD 3.3 with
GNU gdb 4.16.1.

If you analyze the code which led to this write() you will see that
s->op was used by substdio_flush() to call allwrite() (looks inlined).
allwrite in turn uses op to call write. Since you got into write() I
have to assume that op has a valid value and not 0x67676767 as gdb
claims.

Thanks
Greg