In ander nieuws: ROT13 is gekraakt!

En daar hebben ze natuurlijk gelijk in. Het heeft geen zin om de cliënt te updaten want kwaadwillenden kunnen dan altijd een oude versie van de cliënt gebruiken, of zelf een cliënt maken die dit probleem genereert.
Als dit echt een probleem is, moet je dit in de servers aanpassen.

Waarom niet in beide, server en clients?

Dat was ook mijn eerste reactie na het lezen van het artikel. Maar de onderzoeker bedoelt niet dat je met de kwetsbare mail clients afzenderadressen kunt spoofen (ja duh), maar dat kwetsbare mail clients in ontvangen mails het From: adres niet laten zien zoals je zou verwachten!

Zie https://www.mailsploit.com/.

Nah, gewoon nog een keer ROT13 encrypten. Moet je van goeden huize komen om dat te vinden.

De ontdekkers omschrijven het probleem als

Kwaadwillenden bepalen niet welke mail client een slachtoffer gebruikt.

Won't fix is niet een goed antwoord op securityproblemen. Dan heb je wat uit te leggen. Het verbaast me overigens niet van Mozilla, die laten jarenlang overduidelijke problemen zitten omdat er een paar developers met een tekort aan social skills zich willen laten gelden en niet met kritiek kunnen omgaan. Dat soort types komen vaak voor in de open source wereld. "Works for me" is hun adagium.

Ceasar draait zich 13 keer om in zijn graf , zullen we maar over gaan op ROT14 ;-)

Klopt, maar dat staat hier ook niet ter discussie. Het gaat om zaken als DMARC misleiden door spoofing. En een ontvangende cliënt kan nooit een DMARC controleren, dat kan alleen de ontvangende server betrouwbaar doen. Als het dus om een cliënt met bugs gaat, moet het om de verzendende cliënt gaan.

Ik heb net die testsite bekeken. Ze bedoelen toch de ontvangende cliënt, hoewel ik dan het hele verhaal over DMARC niet goed begrijp.

Ik heb ook via die testsite een mailtje aan mezelf gestuurd. Met apple mail cliënt zie ik echter niets van misleiding. Ik zie gewoon een heel corrupt afzenderveld.

Via Gmail zie ik:


En via mijn eigen server zie ik:

En ook als ik naar DMARC kijk zie ik geen misleiding:


Ik zie duidelijk wie de echte afzender is.

Edit: Op mijn telefoon staat blue mail. Ook daar zie ik alleen een corrupte afzender.
Ook via Thunderbird op mijn laptop zie ik alleen een corrupte afzender. En ik zie dat het DKIM getekend is door mailsploit.com. Dus ook daar geen misleiding.

Dus bij alle 3 geteste mail cliënten zie ik niets van spoofing

DMARC word niet gespoofed. De MTA doet netjes een DMARC check op het verzendende domein. Door bugs in een hele stapel clients geven deze het verzendende domein echter niet goed weer. Oftewel, client side problem bij de *ontvangende* client. Mailsploit heeft een script om het te testen en is sowieso de moeite van het lezen waard. Betere uitleg dan dit artikel.

Dit probleem kan het best worden opgelost op mailservers omdat dat de aangewezen plek is om malformed From te schonen. Dat is de sterkste manier om dit probleem aan te pakken, en dat beaamt de ontdekker van deze exploit zelf ook:

"Haddouche tells WIRED that email providers and firewalls can also be set to filter out his attack, even if email clients remain vulnerable."

waarmee je de spoofing dus ook voorkomt bij Opa Harrie de internet leek die zijn PC nooit update. Dit is een logische conclusie indien je de exploit ook inhoudelijk begrijpt. Het is immers sterk om een string te lezen tot de string terminator \0, de fout is dat de valide data (de echte From) voorafgegaan wordt door \0, en die fout wordt niet veroorzaakt door de mail client.

Sterker, het is ronduit misleidend om dit een 'lek in mailclients' te noemen in de kop van dit artikel, en met die onzorgvuldigheid zet security.nl de leken hier op het verkeerde been. Het is een zwakte in MTAs. Toegegeven, mailclients -kunnen- deze zwakte mitigeren met extra code, maar dat is zoals hierboven ook al meerdere malen terecht opgemerkt, symptoombestrijding.

Een gebrek aan vakkennis wel?

Je anonieme social skills en geldingsdrang druipen er van af. Kan je wel met kritiek om gaan?

Dat Mozilla werkelijk niks gaat doen is onjuist. UIt dit probleem zijn een vijftal bug reports onstaan waar één van serieus naar gekeken wordt op dit moment, drie staan nog klaar voor beoordeling en de laatste is afgeschoten "Bug 1423440 - Remove @ from real name" met als reden dat dit heel veel klachten gaat opleveren als bijvoorbeeld je bedrijf "Man @ Work" heet.

Zie onderstaande link voor meer informatie:
https://bugzilla.mozilla.org/show_bug.cgi?id=1423430

Ja, dat zie je ook hoe ik niet reageer op kritiek dat ik fout zat door Briolet (wat niet zo is). Briolet heeft zichzelf hersteld, dus reageren is niet nodig.

Jijbakken (tu quoque) draagt niet bij aan de discussie.

Uit de link maak ik op dat je ontwikkelaar bent, want ik kan hem niet zien (access denied). Er zijn diverse manieren om dit op te lossen vrijwel zonder false positives. Als andere partijen het ook kunnen, moet Mozilla het ook lukken.

Technisch: Man @ Work is geen email adres en behoeft dus geen aanpassing. Er staan spaties in en het "domein" bestaat uit slechts 1 label. Bij een email adres verwacht je minstens 2 labels (d.w.z.: domeinnaam.tld). Domeinnamen en tld moeten aan regels voldoen. Het is misschien niet nodig die regels te handhaven.

Een van de tests is deze:
From: "potus@whitehouse gov" <demo@mailsploit com>
een alternatieve schrijfwijze zou zijn:
From: potus@whitehouse gov <demo@mailsploit com>
(onschadelijk gemaakt door punt voor tld te verwijderen, de adressen vormen 1 aaneengesloten whitespaceloze string)

Op dergelijke emails moet een mail filter ingrijpen. Een mail client kan een duidelijke waarschuwing tonen. Sommig email clients tonen geen email adressen alleen de omschrijving, en dat maakt dit zeer gevaarlijk.

Ik ben overigens tegen mail server level rewriting. Email moet worden doorgegeven as-is. Geen gerommel. Dat is in het verleden al zeer gevaarlijk gebleken, met name bij Microsoft Exchange, die "defecte" email automagisch repareert. Daardoor kan bijvoorbeeld een bijlage met virus door Microsoft Exchange worden hersteld nadat een voorgeschakelde mailscanner er geen bijlage in kon ontdekken.

Nee ik ben geen ontwikkelaar en ook heb ik geen account op hun bug tracker het is voor mij gewoon publiekelijk inzichtbaar, ik kan de site gewoon openen met Chrome en Safari. Wel kan ik even een update geven mocht niemand bovenstaande URL kunnen openen:

De bug die als urgent werd bestempeld binnen Mozilla vanmiddag is opgelost en staat momenteel gereed voor test. Het ging om een module JS Mime die een zogenaamde null-byte of wel een soort van spatie verkeerd doorgaf waardoor de verwerking naar de GUI zeg maar niet goed ging.

Als ik het goed begrijp zal de mailclient na de patch is doorgedrukt is de e-mails met een 0 byte character wel binnen komen maar het hele from veld zal vervangen worden met de tekst "Invalid" of iets dergelijks. Hieronder de laatste reacties van de bug tracker:

-------------

Ben Bucksch (:BenB) (Reporter) -
Comment 3 • 4 hours ago
@Jörg, as I said, we should simply strip the null byte. Not replace it.

---------

Ben Bucksch (:BenB) (Reporter) -
Comment 4 • 4 hours ago
If we replace it, I would consider it an active attack, and I'd replace the *entire* local part with "[invalid]". No legitimate email address contains null bytes, so we should proactively protect the user.

----------------

Jorg K (GMT+1) (Assignee) -
Comment 5 • 44 minutes ago
Created attachment 8935130 [details] [diff] [review]
jsmime.patch - WIP

Here's your fix.

Note that is doesn't work when the message is already in the mail store since the old header will be served by Mork from the DB to the UI.

I need to add some tests.

---------------

Jorg K (GMT+1) (Assignee) -
Comment 6 • 17 minutes ago
Created attachment 8935141 [details] [diff] [review]
jsmime.patch (v2)

Final fix with test. Anyone can review ;-) First in, best dressed.

Hier een overzicht van de 5 bugs die hieruit onstaan zijn en ik zet gelijk even de huidige status erbij:

Bug 1423432 - From addresses with null character are cut off (opgelost/test)
Bug 1423437 - Do not unescape email addresses (wordt beoordeeld)
Bug 1423439 - Strip highly unusual characters from the email address (wordt beoordeeld)
Bug 1423440 - Remove @ from real name (Dit verzoek is gesloten/Rejected)
Bug 1423444 - Remove domains from real name part (Is nog niks mee gedaan " Pending" )

Aan de discussies in de twee bugs met status beoordeeld, ziet het er naar uit dat de Mozilla ontwikkelaars dit toch wel graag willen oplossen. Ze zijn er alleen nog niet uit hoe het aan te pakken.

Een email-client die geen last had van dit lek, blijkt Oeclassic, https://www.oeclassic.com/
"OE Classic is completely unaffected".

Ik begin steeds meer waardering te krijgen voor deze client.
Simpel en doeltreffend, en ook nog behoorlijk veilig.
De betaalde Pro-versie (2.8) heeft er weer een aantal nieuwe features bij gekregen zie ik.
Men is van plan om het verder uit te bouwen, maar neemt daar wel de tijd voor...

De titel ("Lek in e-mailclients maakt het mogelijk om afzender te spoofen") is correct.

MTA's controleren (meestal) het juiste adres en ze kunnen een email als geverifieerd doorlaten of markeren. De ontvanger ziet echter in een kwetsbare mail lezer als Thunderbird een geheel ander adres afgeleid uit het "display from" adres, en trekt wellicht de (onjuiste) conclusie dat het de werkelijke verzender is. Dat is natuurlijk niet zo, het is gespoofed d.m.v. een van de exploittechnieken. Zelfs een succesvolle reply naar het valse From: adres is mogelijk.

Het is dus een zwakte in email clients dat de verkeerde email adressen worden getoond. Mail client producenten dienen het dus te herstellen.

Dit soort mensen werken ook gewoon bij bedrijven hoor.

Kwestie blijft, klopt de implementatie volgens RFC? Daarna, klopt de RFC?