image

Mozilla dicht spoofinglek in e-mailclient Thunderbird

dinsdag 26 december 2017, 09:04 door Redactie, 11 reacties

Mozilla heeft een beveiligingsupdate uitgebracht die meerdere kwetsbaarheden in de e-mailclient Thunderbird verhelpt, waaronder een lek dat het mogelijk maakt om de afzender te spoofen. In Thunderbird 52.5.2 zijn in totaal vijf kwetsbaarheden gepatcht, waarvan er één als ernstig is aangemerkt.

Dit probleem bij het verwerken van WebGL-content treft alleen Thunderbird-gebruikers op Windows en zou het mogelijk maken voor een aanvaller om willekeurige code op het systeem uit te voeren. Daarnaast zijn er ook drie kwetsbaarheden verholpen met betrekking tot RSS-feeds. Een aanvaller zou via kwaadaardige RSS-feeds JavaScript of CSS binnen de mailbox kunnen uitvoeren en bijvoorbeeld informatie achterhalen, zoals een gebruikersnaam.

De vijfde kwetsbaarheid betreft een spoofinglek waardoor het voor een aanvaller mogelijk is om het e-mailadres van de afzender te spoofen en elk willekeurig e-mailadres op te geven. Door het gebruik van zogeheten "null characters" werd het echte e-mailadres van de afzender niet binnen Thunderbird weergegeven. Het spoofinglek, met de naam Mailsploit, werd eerder deze maand geopenbaard en bevindt zich in meerdere e-mailclients. Updaten naar de nieuwste Thunderbird-versie kan via de automatische updater en Mozilla.org.

Reacties (11)
26-12-2017, 10:07 door karma4
Ik moest even nadenken wat dat inhield =het gebruik van zogeheten "null characters"=.
Het is de basis hoe stringfuncties in C afgehandeld worden 00 einde string word 00-00 einde array strings (no arg).
Als de input validatie hiervoor gevoelig is dan zal dat net zo'n algemene programmeer valkuil als de bufferoverrun zijn.

In veel protocollen standaarden is er een vast blok ofwel structure waarin vastgelegd wordt wat volgt.
Natuurlijk zijn er dan issues op te lossen maar het is een strictere definitie in de aanpak dan we zien wel wat te doen op een escape sequence.
26-12-2017, 11:12 door Krakatau - Bijgewerkt: 26-12-2017, 11:14
Door karma4: Ik moest even nadenken

Goh... DAT zal niemand verbazen!

Door karma4: wat dat inhield =het gebruik van zogeheten "null characters"=.
Het is de basis hoe stringfuncties in C afgehandeld worden 00 einde string word 00-00 einde array strings (no arg).

Echt waar joh? (open deur)

Door karma4:
Als de input validatie hiervoor gevoelig is dan zal dat net zo'n algemene programmeer valkuil als de bufferoverrun zijn.

In veel protocollen standaarden is er een vast blok ofwel structure waarin vastgelegd wordt wat volgt.
Natuurlijk zijn er dan issues op te lossen maar het is een strictere definitie in de aanpak dan we zien wel wat te doen op een escape sequence.

En dan uiteindelijk nog de plank totaal misslaan! Als die null-characters ge-escaped zouden zijn met een escape sequence dan zou er juist geen probleem zijn! Het probleem is juist ontstaan doordat men geen escapes gebruikt en er dus geen escape sequences zijn en de echte null-characters gewoon worden doorgelaten.
26-12-2017, 11:59 door karma4
Door Krakatau:
En dan uiteindelijk nog de plank totaal misslaan! Als die null-characters ge-escaped zouden zijn met een escape sequence dan zou er juist geen probleem zijn! Het probleem is juist ontstaan doordat men geen escapes gebruikt en er dus geen escape sequences zijn en de echte null-characters gewoon worden doorgelaten.

Je moet andersom denken zoals bij het hayes modem protocol. Het is idioot dat je van een tekenreeks als escape functie afhankelijk bent. Dat bij Unix C string de "escape uit de escape" als een enkele escape voor it-newbies/volgelingen hebben aangeduid en dat vervolgens als gangbaar aangenomen is een bekende betekenis omdraaiing.

Dat klungelige gedoe van het niet weten van die 00 betekenis zie ik bij grote commerciële producten als scripting fouten terug. Unix/Linux wereld met helaas her en der nare gevolgen. Die open deur is voor de gangbare ICT-er behoorlijk verborgen.

Ik heb je al een tijdje gemist. Nog de beste kerstwensen en een goed nieuwjaar.
26-12-2017, 14:35 door Krakatau - Bijgewerkt: 26-12-2017, 14:37
Door karma4:
Door Krakatau:
En dan uiteindelijk nog de plank totaal misslaan! Als die null-characters ge-escaped zouden zijn met een escape sequence dan zou er juist geen probleem zijn! Het probleem is juist ontstaan doordat men geen escapes gebruikt en er dus geen escape sequences zijn en de echte null-characters gewoon worden doorgelaten.

Je moet andersom denken zoals bij het hayes modem protocol. Het is idioot dat je van een tekenreeks als escape functie afhankelijk bent. Dat bij Unix C string de "escape uit de escape" als een enkele escape voor it-newbies/volgelingen hebben aangeduid en dat vervolgens als gangbaar aangenomen is een bekende betekenis omdraaiing.

Dat klungelige gedoe van het niet weten van die 00 betekenis zie ik bij grote commerciële producten als scripting fouten terug. Unix/Linux wereld met helaas her en der nare gevolgen. Die open deur is voor de gangbare ICT-er behoorlijk verborgen.

Null-terminated strings hebben niets met Unix/Linux te maken. Pogingen tot verbeterde mechanismen ook niet.

https://en.wikipedia.org/wiki/Null-terminated_string

Door karma4: Ik heb je al een tijdje gemist. Nog de beste kerstwensen en een goed nieuwjaar.

Krakatau, terug van weggeweest! Idem.
26-12-2017, 14:59 door karma4
Door Krakatau:
Null-terminated strings hebben niets met Unix/Linux te maken. Pogingen tot verbeterde mechanismen ook niet.
Integendeel zie: http://man7.org/linux/man-pages/man3/strncpy.3.html C is de basis van Unix/Linux.
Dat komt terug in de shell scripting $* of zelf strings uitpluizen https://www.tutorialspoint.com/unix/unix-special-variables.htm Hier gaan al de professionele scripts zou vaak de fout in dat het echt droevig is.
Bijzondere tekens zoals een spatie in bestandsnamen moet je echt vermijden want de cots producten kunnen er niet tegen.

Wat jij verbeterde mechanismes noemt was de standaard was de standaard in S/360 iets duurder maar veel betrouwbaarder en minder foutgevoelig. Je ziet deze aanpak bijvoorbeeld terug met :
https://en.wikipedia.org/wiki/IPv6_packet#Fixed_header Zou wat fraais geworden zijn als ze op hayes geabaseerd hadden.
26-12-2017, 15:40 door Anoniem
Jullie maken je druk om niks. Eh, ik bedoel null.
26-12-2017, 17:44 door Krakatau
Door karma4:
Door Krakatau:
Null-terminated strings hebben niets met Unix/Linux te maken. Pogingen tot verbeterde mechanismen ook niet.
Integendeel zie: http://man7.org/linux/man-pages/man3/strncpy.3.html

Dat zeg ik. Het is een grotendeels C ding.

Door karma4: C is de basis van Unix/Linux.

Wat nou Unix/Linux? MS-DOS en Windows zijn ook in C geschreven. Onder andere want eigenlijk zowat alle systeemsoftware is in C(++) geschreven.
26-12-2017, 19:11 door karma4
Door Krakatau:
Wat nou Unix/Linux? MS-DOS en Windows zijn ook in C geschreven. Onder andere want eigenlijk zowat alle systeemsoftware is in C(++) geschreven.
Eens en toch erg dat ze de zelfde foute basis hebben in dit soort basis taal functies. Lijken ze allemaal toch erg op elkaar.

In de begintijd wat juist de processor met dd bijbehorende assembler taal leidlend. Het kostte nogal wat moeite om daar gestructureerde goede prorogramma's mee td krijgen. Met hogere level programmeertalen zou dat vanzelf goed komen.
Nou hebben we weer een voorbeeld dat het niet zo is.
27-12-2017, 09:52 door Krakatau
Door karma4:
Door Krakatau:
Wat nou Unix/Linux? MS-DOS en Windows zijn ook in C geschreven. Onder andere want eigenlijk zowat alle systeemsoftware is in C(++) geschreven.
Eens en toch erg dat ze de zelfde foute basis hebben in dit soort basis taal functies. Lijken ze allemaal toch erg op elkaar.

Er is helemaal geen 'foute basis in de basis taal functies'. Er is alleen ooit een beslissing gemaakt waarbij NULL-terminated strings de voorkeur kregen. Niets mis mee, gewoon rekening mee houden in je software.

Door karma4: In de begintijd wat juist de processor met dd bijbehorende assembler taal leidlend. Het kostte nogal wat moeite om daar gestructureerde goede prorogramma's mee td krijgen. Met hogere level programmeertalen zou dat vanzelf goed komen. Nou hebben we weer een voorbeeld dat het niet zo is.

Je roept echt maar wat nietwaar?
27-12-2017, 16:58 door karma4
Door Krakatau:
Je roept echt maar wat nietwaar?
Nope ik heb de tijd dat het allemaal opgebouwd werd in de ict bewust meegemaakt. 6502 assembler met een paar andere en de switch naar cobol fortran en de switch naar C.
Met vaak genoeg de onzin argumenten en duidelijke fouten in haneleidingen leerboeken van leveranciers
Ns-dos 2.1 in C? Het zou me verbazen de c compiler was nogal rudimentair in die tijd. Belangrijkste feature direct cpu registers aanspreken.

Opgegroeid met gestructureerd werken Edsger Dijkstra filosofie was leidend. Dat null als escape voor een string raar is blijft een probleem . Probeer eens met utf8 en je gaat echt nat.
27-12-2017, 21:08 door Krakatau - Bijgewerkt: 27-12-2017, 21:09
Door karma4:
Door Krakatau:
Je roept echt maar wat nietwaar?
Nope ik heb de tijd dat het allemaal opgebouwd werd in de ict bewust meegemaakt. 6502 assembler met een paar andere en de switch naar cobol fortran en de switch naar C.
Met vaak genoeg de onzin argumenten en duidelijke fouten in haneleidingen leerboeken van leveranciers

Leverancier met fouten == Microsoft?

Door karma4: Ns-dos 2.1 in C? Het zou me verbazen de c compiler was nogal rudimentair in die tijd. Belangrijkste feature direct cpu registers aanspreken.

Dit begint inderdaad een beetje een haantjesstrijd te worden ;-) Mogelijk was het inderdaad (net) voor de C tijd.

Door karma4: Opgegroeid met gestructureerd werken Edsger Dijkstra filosofie was leidend. Dat null als escape voor een string raar is blijft een probleem . Probeer eens met utf8 en je gaat echt nat.

Helemaal niet (UTF-8) want dat escape je gewoon. Moet je wel beseffen dat het nodig is en het ook doen.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.