Mozilla dicht spoofinglek in e-mailclient Thunderbird
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.
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.
Goh... DAT zal niemand verbazen!
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)
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.
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.
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
Krakatau, terug van weggeweest! Idem.
Null-terminated strings hebben niets met Unix/Linux te maken. Pogingen tot verbeterde mechanismen ook niet.
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.
Null-terminated strings hebben niets met Unix/Linux te maken. Pogingen tot verbeterde mechanismen ook niet.
Dat zeg ik. Het is een grotendeels C ding.
Wat nou Unix/Linux? MS-DOS en Windows zijn ook in C geschreven. Onder andere want eigenlijk zowat alle systeemsoftware is in C(++) geschreven.
Wat nou Unix/Linux? MS-DOS en Windows zijn ook in C geschreven. Onder andere want eigenlijk zowat alle systeemsoftware is in C(++) geschreven.
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.
Wat nou Unix/Linux? MS-DOS en Windows zijn ook in C geschreven. Onder andere want eigenlijk zowat alle systeemsoftware is in C(++) geschreven.
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.
Je roept echt maar wat nietwaar?
Je roept echt maar wat nietwaar?
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.
Je roept echt maar wat nietwaar?
Met vaak genoeg de onzin argumenten en duidelijke fouten in haneleidingen leerboeken van leveranciers
Leverancier met fouten == Microsoft?
Dit begint inderdaad een beetje een haantjesstrijd te worden ;-) Mogelijk was het inderdaad (net) voor de C tijd.
Helemaal niet (UTF-8) want dat escape je gewoon. Moet je wel beseffen dat het nodig is en het ook doen.
Deze posting is gelocked. Reageren is niet meer mogelijk.
Netwerk Security Engineer
Luchtverkeersleiding Nederland
Als Netwerk Security Engineer ontwerp en optimaliseer je onze technische netwerk- en beveiligingsinfrastructuur. Je stuurt tech-nische veranderingen aan op basis van de gestelde architectuur kaders en helpt mee met de uitvoering ervan. Ben jij een gedreven professional met passie voor netwerk-beveiliging? Dan is deze functie als Netwerk Security Engineer bij Luchtverkeersleiding Nederland (LVNL) iets voor jou!
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.