Misxchien heeft de Rusische maffia hem een aanbod gedaan dat hij niet kon weigeren.

Dit is een lastig ethische kwestie. Iemand besteedt tijd aan het zoeken naar kwetsbaarheden in software (welliswaar gemaakt door bedrijven die hem geen opdracht hebben gegeven voor dat onderzoek), vindt kwetsbaarheden, verpakt die in een plugin voor een penetration testing tool, en biedt deze openlijk te koop aan.

Voor zover ik weet is Mozilla niet bereid om te betalen voor exploits, of dat in dit geval ook zo is weet ik niet.

Is dit chantage of gijzeling, of leidt het er uiteindelijk toe dat softwarefabrikanten serieuzer gaan zorgen dat er geen kwetsbaarheden meer te vinden zijn in hun software (c.q. dat het er zo weinig zijn dat de bereidheid wel bestaat om te betalen voor dit soort onderzoek)?

Ik weet dat de Buma-Stemra niet erg populair is bij veel lezers van deze site, maar waarom heb je als security onderzoeker niet op de een of andere manier recht op inkomsten, bijv. via een organisatie die een soort "auteursrechten" van beveiligingsonderzoek bewaakt en managet?

Is Evgeny Legerov een ordinaire zakkenvuller, of is hij slechts een boodschapper en zouden wij als gebruikers juist kwaad moeten worden op softwarefabrikanten (het zou in dit geval weer eens gaan om een bufferoverflow, dat *mag* gewoon niet meer voorkomen in deze tijd, gebruik maar een andere programmeertaal dan C/C++ als je daar niet mee overweg kunt) omdat zij ons voortdurend aan dit soort kwetsbaarheden blootstellen?

Graag onderbouwde antwoorden.

Wat stel jij dan voor ? Ik denk dat C/C++ toch nog steeds de enige serieuze oplossing is als je cross-platform wilt ontwikkelen. Natuurlijk, Java is cross-platform maar dat zou voor mij echt een afknapper zijn en een reden om Firefox links te laten liggen. Ik vind Java hartstikke mooi maar niet voor de desktop.

De programmeertaal is niet het probleem, het gaat om de kwaliteit van de programmeur. In elke taal kun je goed programmeren... En het percentage programmeurs wat goed programmeren kan is IMHO een wiskundige constante...

Wat niet betekend dat'ie ook reageert?

Kom op nou Peter.. *zucht*


staat daar maken, of krijgen?


Dussss...

Een stukje uit nsHtml5Parser.cpp (FF v3.60, waarvan ik geen idee heb ik of deze ooit wordt uitgevoerd of zelfs meegecompileerd wordt), kijk eerst naar het onderste deel van de code:Als in de onderste regel geldt dat mSniffingLength + aCount groter is dan NS_HTML5_PARSER_SNIFFING_BUFFER_SIZE dan heb je natuurlijk te maken met een ordinaire bufferoverflow. Bovendien zou mSniffingBuffer naar een kleinere buffer dan NS_HTML5_PARSER_SNIFFING_BUFFER_SIZE kunnen wijzen (zou op een kleinere buffer kunnen zijn geïnitialiseerd of zou daarna kunnen zijn opgehoogd), maar dit lijkt de enige plaats in de source waar geheugen voor de buffer wordt gealloceerd.

Indien mSniffingLength + aCount >= NS_HTML5_PARSER_SNIFFING_BUFFER_SIZE dan wordt in het bovenste stuk gelukkig een bufferoverflow voorkomen doordat de routine verlaten wordt voordat je bij de onderste sectie met memcpy aankomt.

Maar dit is wel afschuwlijke code, de kans dat een andere programmeur (of dezelfde na enige tijd) ergens boven die memcpy iets wijzigt waardoor dit wel tot een bufferoverflow leidt is niet denkbeeldig. Het gaat hier om strings, waarom worden er geen stringclasses gebruikt die bijna al dit soort leed kunnen voorkomen? (en waarbij je bovendien slimmer memory management kunt doen, er even vanuitgaande dat ze new() voor dit doel niet ergens hebben geoverload).

Op een andere plaats in de source vond ik iets dat best wel eens wel tot een bufferoverflow zou kunnen leiden, als ik tijd heb zal ik dat eens verder onderzoeken (nee, ik ga hier niet vertellen wat en waar). Alleen al het feit dat een redelijk ervaren programmeur er enorm veel tijd in moet stoppen om te snappen wat een stuk source doet en of er wellicht fouten in zitten betekent een -m.i. veel te groot- risico.

Ansi C is gewoon te link voor allerlei ordinaire stringoperaties (tenzij zorgvuldig in een optimized library toegepast). Zaken als strcpy(), strcat(), memcpy() en complexe pointeroperaties hoor je m.i. niet in "worker" C++ routines tegen te komen; de kans op fouten daarin is gewoon te groot. Dat heeft de praktijk ondertussen wel bewezen, toch?

Ik vind dit niet geen afschuwelijke code (afgezien van het onnodige 'goto' statement een paar regels erboven) . Het is niet bijzonder om uitzonderingen of bijzondere situatie af te vangen en dan vervolgens te eindigen met een stuk default code die uitgevoerd wordt als al die bijzondere gevallen niet van toepassing zijn. Ik denk dat je dit in heel veel code tegen komt.

Dat hier geen string class wordt gebruikt lijkt me ook niet zo gek. Het is een method welke een ruwe buffer moet scannen op de aanwezigheid van een Unicode BOM karakters. Dat is geen string handeling.

Dat memcpy niet veilig is ben ik met je eens. Dat is de reden dat Microsoft ook allemaal "secure" versies van alle C runtime functies heeft gemaakt (zie: http://msdn.microsoft.com/en-us/library/wd3wzwts%28VS.80%29.aspx). Maar Mozilla kan daar waarschijnlijk geen gebruik van maken omdat ze denk ik niet Visual C++ gebruiken als compiler voor de Windows versie. Om het over andere platformen nog maar niet te hebben.

Als softwaremaker zijnde gebruik je het liefst dezelfde code voor alle platformen waar de software voor geschreven wordt. Architectuur of platform afhankelijke code probeer je zo veel mogelijk te vermijden omdat dit alleen de complexiteit vergroot en daarmee de kans op fouten. Memcpy is een standaard C/C++ library functie en is dus overal aanwezig. De versies van MS zijn dat niet.

Mee eens. Mozilla zou wel een macro kunnen maken welke in ieder geval op Windows de safe varianten gebruikt en de klassieke varianten op de andere platformen. Dat geeft op Windows dan in ieder geval wat extra veiligheid. Maar goed, dan zouden ze ook Visual C++ moeten gebruiken en dat doen ze denk ik niet (heb het niet uitgezocht).

Zal duitsland nu ook oproepen om de firefox browser niet te gebruiken (zoals ze met ie deden)?

Als je geen string class tot je beschikking hebt waar je unsigned chars met willekeurige waarde in kunt stoppen verzin dan maar een byte array class die zaken als lengte e.d. voor je in de gaten houdt.

Nogmaals de source als toelichting, nu met regelnummers:Wat betekent dat:
[1]Als mSniffingBuffer een waarde ongelijk nul heeft {
[2] maak dan een unsigned byte array aan ter grootte van NS_HTML5_PARSER_SNIFFING_BUFFER_SIZE
[3]}
[4]Kopieer aCount bytes vanaf adres aFromSegment naar adres mSniffingBuffer op offset mSniffingLength

Problemen:
(A) stel dat bij [1] mSniffingBuffer een waarde ongelijk nul heeft bijv. omdat deze naar een array kleiner dan NS_HTML5_PARSER_SNIFFING_BUFFER_SIZE wijst?
(B) direct voor [4] ontbreekt een check op mSniffingLength + aCount <= NS_HTML5_PARSER_SNIFFING_BUFFER_SIZE

Op zich is memcpy() helemaal niet onveilig. Het probleem zijn de pointers (en -operaties) die daar onherroepelijk mee verbonden zijn, en daar worden statistisch gezien te veel fouten mee gemaakt. Daarom moet je m.i. dat soort operaties in separate library-achtige sources stoppen die je goed test en waar zelden wijzigingen in nodig zijn. En die bestaan in dit geval al, een byte array waarvan je de lengte kunt opvragen (of die z'n lengte dynamisch aanpast) zijn toch niet meer zo bijzonder in deze tijd?

De programmeur die dit schreef was misschien slim genoeg, maar het betreft open source, d.w.z. ook anderen moeten dit kunnen oppakken, en die kunnen te makkelijk fouten maken in de code eromheen. Dit is gewoon geen defensive programming.