|
The HBX Networks |
GMail
Messages are Vulnerable to Interception |
January 12, 2005 |
||||||||||||
It all started about 3 days ago when MrYowler and I were working on a mailing list script to send out a batch of newsletters for a free hacker-friendly shell service we operate. We made the decision to keep it simple; a Perl script based upon the Net::SMTP CPAN module. Being the Perl guru that MrYowler is (shut up! people will start having expectations of me! ;-P), he had one whipped up in about 20 minutes. In the course of testing the script, we cranked out 10 newsletters to our GMail inboxes. We were a little shocked with that happened next. MrYowler opened up his mailbox, and noticed the email had arrived just fine. He clicked on the subject line, and as expected, the message showed correctly. However, when he clicked the "Show options" link, the "Reply To" field in the email header that GMail displayed contained what appeared to be HTML code! Upon further inspection, we realized that it was the message body of another person's HTML-formatted email message.
Wondering if something had happened during the message transmission, we viewed the message source via GMail's "Show original" link. In the source, we did not see any of the HTML code that GMail was showing us. No HTML at all, as we did not even use it in our newsletter. It appeared as a regular run-of-the-mill plain text message. We became curious as to what had gone wrong, and whether it was an error in the script, or in the GMail messaging system. We examined the the output of our Perl script, and discovered that it was not transmitting the "From" header (in the message body) correctly - the trailing ">" character was missing in the address area. Where it should have been "From:<hbxnetworks@gmail.com", we had "From:<hbxnetworks@gmail.com". This, apparently, was enough to get GMail to provide us with some portion of someone else's messages. We speculate that there is a subroutine which determines where the "From" address component of a message, ends - and that this subroutine relies upon the closing ">" bracket to distinguish this end. When unable to find this character prior to a carriage return, it simply continues to read past the end of the allocated buffer for this component, until it either encounters this character in whatever data happens to be there, or until some upper buffer size limit is reached. We remain unsure of that buffer size limit, and whether, in fact, one exists. We propose that the correct solution to this problem, might be to also search for non-displayable data, such as carriage returns, in this area, and to terminate the field on this basis. Alternatively, if the size of the field is determined separately, when allocated; that information could be retained, as a criterion for failure conditions, when the field is parsed. It is possible that a large buffer area is being allocated, and then being populated only partially. This being the case (if so), then the data that we are seeing is what was left in memory, after the last time that this memory area was returned to the memory manager, and this error does not represent a buffer overflow, but rather, a poorly-managed boundary condition in the GMail server-side software. Regardless of the specific failure, the result is a compromise of the privacy of communications over GMail. As demonstrated in the examples (below), message content and address information are easily - if somewhat randomly - available to unintended recipients. Usually, this only permits an attacker to examine recently-arrived spam in random user's inboxes - but (as noted in one example) message content does occasionally become more interesting.
We do realize that GMail is an invitation-only service, in a beta-test state of development. Nevertheless, many people rely upon GMail heavily, and many more people are forced to communicate with GMail users, because of this reliance. These people should expect their communications to be vulnerable to interception, at least until GMail corrects the issue. And the appearance of this issue, at the user level, probably indicates a failure in GMail's code review and/or quality assurance standards, which may result in other, similar errors. We did not explore GMail for additional such errors, but based upon the nature of this one, we are confident that such exploration would bear interesting fruit. (Note to GMail's development teams: we are available for hire! Cheaply! ;-P) So... If you are a regular GMail user - or someone that corresponds with one - you might want to either rethink the privacy of your communications, or perhaps make some noise with the folks at Google's email service. And don't forget to tell them that MrYowler and I need jobs... ;-P (Note that we are using a GMail address, so any job offers are probably not going to be well-kept secrets... ;-P)
|
||||||||||||||
