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
