Google lost onderscheppingen Gmail-berichten op

Twee leden van HBX Networks hebben enkele dagen geleden een serieus lek gevonden in Googles mailsysteem Gmail. Bij toeval werd ontdekt dat berichten van andere personen konden worden onderschept via eigen accounts. Tijdens het testen van een Perl-script om nieuwsbrieven naar mailinglijsten te versturen, hadden de twee ontwikkelaars de From-header in het mailbericht vergeten af te sluiten. In plaats van bijvoorbeeld From:<[e-mail]> werd deze header zonder het laatste karakter verzonden, dus als From:<[e-mail]. Na het ontvangen en openen van het bericht in Gmail en het vervolgens klikken op de opties-knop, bleken gedeeltes van andermans berichten in beeld te verschijnen.

Google heeft inmiddels het lek gedicht en onduidelijk blijft hoe lang het bestaan heeft. De onderschepte informatie bestond veelal uit complete of gedeeltelijke berichten van willekeurige gebruikers. In de meeste gevallen ging het daarbij om spamberichten. Echter zaten er ook bevestigingsberichten met gebruikersnamen en wachtwoorden voor webdiensten tussen. De ontdekkers vermoeden dat de onderschepte berichten afkomstig zijn uit achtergebleven informatie in het geheugen op de servers van Gmail. Door het ontbreken van het sluitende karakter in de From-header zou mogelijk deze informatie ook ingelezen worden.

Reacties (29)

[Peter]

Dit is niet zo netjes van google zelf, zeker omdat het toch een vrij basic bug is (verkeerde invoerwaarde), ondanks het feit dat juist dit soort bugs snel over het hoofd worden gezien. Daarnaast heeft google ook nog eens mazzel dat het ontdekt is door een eerlijk lid, en niet iemand die constant gaat zitten refreshen (of meerdere e-mails sturen) om zoveel mogenlijk gegevens te verkrijgen.

Het is in ieder geval wel duidelijk waarom GMail nog in de bèta fase zit

[kodak]

"Daarnaast heeft google ook nog eens mazzel dat het ontdekt is door een eerlijk lid, en niet iemand die constant gaat zitten refreshen (of meerdere e-mails sturen) om zoveel mogenlijk gegevens te verkrijgen."

Wees daar maar niet al te zeker van, want er is geen enkele informatie vrijgegeven of er niet al eerder gebruik van is gemaakt. Ik denk niet dat iemand hier dan flink heeft zitten vissen naar andermans berichten, maar van iemand die het al in zn hoofd haalt om het op een bepaalde manier te misbruiken kunnen wel gekkere dingen verwacht worden. Er zijn genoeg personen op de wereld die met genoegen naar dit soort bugs in grootschalige systemen zoeken en de ontdekking koesteren zonder er maar iets over te zeggen tegen Google of wie dan ook. Pas als iemand die het ook misbruikt heeft zn mond voorbij praat of wanneer Google na heeft gegaan of het niet eerder misbruikt is is er pas zekerheid.

[Neus]

Hoe hebben ze dat dan opgelost, het geheugen sneller wissen ?

[Verwijderd]

Gewoon een betere controle op de invoerwaarde. Als programmeur behoor je alle situaties te voorzien en te voorkomen.

Veel voorkomend probleem is bijvoorbeeld mensen die een letter intypen bij een invoerveld voor nummers. Alle rekenformules lopen dan de mist in, dus als programeur moet je dan eerst controleren of de gebruiker alleen cijfers heeft gebruikt.

In dit geval dus eerst controleren of de From-header juist geformateerd is.

[needless to say]

Als programmeur behoor je alle situaties te voorzien en te voorkomen.

Correctie:

als programmeur moet je steeds een evenwicht proberen te vinden tussen controle op gegevens en gebruiksvriendelijkheid van het programma/service en broncode.

Je kan onmogelijk alles voorzien, of bugs zouden niet van deze wereld zijn .

[Mr. B.]

als programmeur moet je steeds een evenwicht proberen te vinden tussen controle op gegevens en gebruiksvriendelijkheid van het programma/service en broncode.

Invoerwaarden die fouten kunnen opleveren behoor je altijd te controleren voordat je applicatie er iets mee gaat doen. De gebruikersvriendelijkheid zit 'm in de manier waarop je de gebruiker wijst op z'n foute invoer.

Je kan onmogelijk alles voorzien, of bugs zouden niet van deze wereld zijn .

Dat is maar al te waar

[Dwar]

Ik denk door te controleren of het afgesloten word en zoniet het alsnog automatich te doen.

[Hoaxbe]

Waarschijnlijk door de tags van die "From" header te sluiten in de code

[Spiller]

Zorgen dat ie in het options scherm een andere pagina laadt?

edit:

Jahoor; hoezo dubbelpost

[Magic]

Waarschijnlijk door het '>' teken niet meer als scheidingsteken te gebruiken

[Equator]

Ik ben bang van niet..
Binnen smtp kan je nl de < en > gebruiken om een vriendelijke naam te scheidne van het werkelijke emailadres.

John Doe <[e-mail]> is dus een correcte invoer voor een to/cc/bcc field.

Het is dus niet eens een scheidingsteken, daar wordt nl. meestal de comma of de punt-comma gebruikt.

[StefSybo]

Waarschijnlijk controleren of die > erachter staat en anders erachter plakken

[Verwijderd]

mayb extra check inbouwen bij de from input controle?

[DRvDijk]

Ik vind het toch wel gek dat zo'n lek überhaupt heeft bestaan. Email-berichten zijn toch duidelijk gespecificeerd (in RFC 822), hoe de headers eruit moeten zien, hoe de headers gescheiden moeten worden van de body (door een lege regel), et cetera. Dat betekent dus dat ze bij het ontwerpen van de dienst daar géén goed gebruik van hebben gemaakt.

Wat ik wil zeggen is dat het standaard regels zijn die voor alle headers hetzelfde zouden moeten zijn, en waarom het dan alleen voor deze header zo is. Zouden er dan niet nog 100 andere headers zijn die ook 'fout' zijn bij gmail?

[Verwijderd]

De verkeerde header is in elkaar geknutseld door het scriptje van die programmeurs:

Tijdens het testen van een Perl-script om nieuwsbrieven naar mailinglijsten te versturen, hadden de twee ontwikkelaars de From-header in het mailbericht vergeten af te sluiten.

Het is dus niet zo dat

ze bij het ontwerpen van de dienst daar géén goed gebruik van hebben gemaakt.

[Mr. B.]

De verkeerde header is in elkaar geknutseld door het scriptje van die programmeurs:
Tijdens het testen van een Perl-script om nieuwsbrieven naar mailinglijsten te versturen, hadden de twee ontwikkelaars de From-header in het mailbericht vergeten af te sluiten.

Het is dus niet zo dat ze bij het ontwerpen van de dienst daar géén goed gebruik van hebben gemaakt.

Jawel. Dat je eigen applicatie geen incorrecte input genereert, wil nog niet zeggen dat andere applicaties dat ook niet doen. Als je input accepteert van andere bronnen dan jezelf dan dien je die input te controleren. Dat is iets wat Google dus nagelaten heeft.

[Olaf van der Spek]

Ik vind het toch wel gek dat zo'n lek überhaupt heeft bestaan.

Zo gek is het niet hoor. Het is net zoals vrijwel alle andere lekker gerelateerd aan het niet (goed) controleren van de invoer.

[Verwijderd]

Ach, eigenlijk maakt het niet zoveel uit. Je mail en data is door google toch al te scannen op inhoud, en na 180 dagen is volgens de US law je mail toch al niet meer prive.

Dus eigenlijk zou het enkel met mails van 180 dagen oud mogen gebeuren. Enne, ik heb niks te verbergen, dus iedereen mag alles van mij weten, toch?

[Verwijderd]

Waar haal je dat een email na 180 dagen niet meer privé zou zijn ?

[Verwijderd]

uit de Electronic Communications Privacy Act

link naar betreffende onderdeel:
http://www.usdoj.gov/criminal/cybercrime/usc2703.htm

en aangezien google in de US gevestigd is.

[Verwijderd]

Mag ik het bevestigings mailtje van je tweakers.net account?

[bitflusher]

daarom is het toch beta??
beta is toch test om dit soort serieuze dingen niet in een final omgeving terecht te laten komen.

voor mij persoonlijk niet meer dan lof voor google omdat:
-het niet uit beta fase is gehaald terwijl het prima leek te werken.
- een lek als dit snel is opgelost.

[ronaz]

Lijkt me niet echt verstandig om een e-mailservice die nog in het beta stadium zit te gebruiken voor gevoelige e-mails.

Zelf gebruik ik gmail alleen voor het ontvangen van funstuff en newsletters (spam) etc.

Ik zal hier zelf nooit mijn credit card gegevens of accountgegevens naar laten mailen.

[Verwijderd]

Ben benieuwd of dit aanzet tot een zoektocht over andere mailservers naar dit soort header-lekjes.

[Verwijderd]

edit:

mod maar als overbodig: link staat al in artikel

Meer info: http://dump.hbx.us/gmail_bug_hack/

Reactie van Chris DiBona (google):

Just so you know, at 10:15am PST mails with the problematic formatting as described in your previous story stopped being accepted into Gmail. Previous emails that had this problem will also no longer will be accessible. If you don't mind, I'd like to take the time to remind Slashdot readers that they can send bugs that may have a security aspect into [e-mail]. If they like, they should feel free to cc me at [e-mail]. We appreciate your patience and we're sorry about the bug.

http://it.slashdot.org/article.pl?sid=05/01/12/1655246&tid=172&tid=215 &tid=217&tid=218

[Verwijderd]

Lol... nu moet google wel uitkijken hoor. Er zal in Amerika vast wel Gmail gebruiker rondlopen die zich nu niet meer veilig voelt en Google aansprakelijk stelt voor een onveilige beta versie.

[boekel]

ik dacht bij het lezen van de titel dat het ging om het onderscheppen van g-mail invites naar hotmail adressen