Full Disclosure mailing list archives
Lame crash in qmail-smtpd and NO memory overwrite according to gdb
From: Gregory Steuck <greg-fulldisclosure () y2004 nest cx>
Date: Mon, 19 Jan 2004 17:53:22 -0800
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 _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Current thread:
- Lame crash in qmail-smtpd and memory overwrite according to gdb, yet still qmail much better than windows Georgi Guninski (Jan 15)
- Lame crash in qmail-smtpd and NO memory overwrite according to gdb Gregory Steuck (Jan 19)