bugtraq - GMail / Google Groups ESMTP software b0f

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>] [day] [month] [year] [list]

Message-ID: <20050207194448.B56663@dekadens.coredump.cx>
Date: Mon, 7 Feb 2005 21:49:36 +0100 (CET)
From: Michal Zalewski <lcamtuf@...ttot.org>
To: bugtraq@...urityfocus.com, vulnwatch@...nwatch.org
Cc: full-disclosure@...sys.com
Subject: GMail / Google Groups ESMTP software b0f

For their popular GMail service, and a newly introduced "enhanced" Google
Groups bells and whistles, Google uses their own, custom-crafted MX
software on a number of load balancing nodes.

Although I am naturally unable to analyze their proprietary software, this
daemon appears to be vulnerable to a trivial buffer overflow
vulnerability. One may connect to their servers to port 25, issue EHLO
followed by approximately four kilobytes of printable characters (the EHLO
command itself is then acknowledged properly), and follow it shortly with
a valid MAIL FROM command. After MAIL FROM, their SMTP daemon at this
particular LB node will apparently crash and become unavailable for
several seconds.

All other connections to the affected LB node (for example,
gsmtp57.google.com), including sessions from other hosts, would also be
terminated at this point, and would also be unable to reach this service
for a period of time.

Issuing subsequent valid EHLOs before MAIL FROM causes the daemon to
survive.

There is a very strong indication for this being a buffer overflow in a
non-forking daemon, rather than a preemptive IDS strike. The threshold for
the number of characters prompting an overflow; the delayed effect of an
overflow; the fact it is affected only by the last EHLO; and the global
unavailability of the service - all are a clear indication of a classic
b0f related crash.

This overflow would likely happen when a line to be written to logfile or
a queue entry is being prepared (and EHLO data is copied to a too small
buffer).

Beyond the DoS potential, there's also probably a good chance for remote
code execution, which for obvious reasons should worry GMail users.

I notified Google today. It is my understanding that they do not routinely
communicate with researchers or the community on security problems in
their code, so I am not coordinating a response in any way. The problem
may or may not be fixed by now.

PS. If that trivial flaw is representative of the quality of server-side
code beyond some of Google services, I would worry - but take this opinion
with a grain of salt.

/mz
Shameless plug: http://lcamtuf.coredump.cx/silence.shtml