Onderzoekers vinden met nieuwe tool 11 beveiligingsbugs in browsers

Onderzoekers van het Georgia Institute of Technology hebben 11 kwetsbaarheden in browsers gevonden, met behulp van een nieuwe analysetool die ze zelf hebben geschreven. Ze hebben 100.000 dollar gekregen van Facebook om verder onderzoek mogelijk te maken.

Het is niet duidelijk in welke browsers de elf kwetsbaarheden zich bevinden; daarover doet het Institute of Technology geen uitspraken. De bugs zijn wel al gedicht en opgelost, stelt het instituut, maar mogelijk zijn de patches nog niet uitgerold; dat zou de terughoudendheid verklaren. Duidelijk is wel dat de analysetool van de onderzoekers, genaamd Caver, in staat is om Chrome en Firefox te onderzoeken. Ook andere C++-software kan worden onderzocht.

De Caver-tool draait realtime mee met een browser om kwetsbaarheden aan het licht te brengen. De tool draait in combinatie met Chrome en Firefox met een overhead van respectievelijk 7,6 en 64,6 procent. De tool is in staat om bijvoorbeeld bad casting-kwetsbaarheden te vinden, waarbij het geheugen kan worden gecorrumpeerd om eigen code uit te voeren. Ook use after free-bugs kunnen worden aangepakt. Daarbij wordt een deel van het geheugen aangesproken nadat het zojuist leeg is gemaakt. Daardoor crasht de software en kan eigen code worden geïnjecteerd.

Volgens de onderzoekers zijn dat de bugs die minder makkelijk te vinden zijn dan stack overflow- en heap overflow-bugs. Facebook heeft de onderzoekers met 100.000 dollar, omgerekend circa 90.000 euro, gesteund om verder onderzoek mogelijk te maken.

Reacties (43)

[ThaStealth]

Waarom steekt Facebook hier geld in (niet dat ik het erg vind) ik snap niet wat de achterliggende gedachte van Facebook kan zijn.
Dat Google/Mozilla dit zouden doen zou logisch zijn, ze kunnen hun browsers beter maken.

Wel veel extra overhead voor Firefox tov Chrome trouwens.

[8088]

Waarom steekt Facebook hier geld in (niet dat ik het erg vind) ik snap niet wat de achterliggende gedachte van Facebook kan zijn.

Als motivatie noemt Facebook o.a. het volgende:

We all benefit from this kind of work—a large part of why Facebook has been successful in serving nearly 1.5 billion people is because we have been quick to introduce and adopt categories of systems and frameworks that prevent whole classes of vulnerabilities at once. As an industry, we need to invest in those kinds of solutions that scale.

Zie ook Internet Defense Prize.

[anargeek]

Ik kan niet anders dan het helemaal eens zijn met deze gedachte van Facebook en het initiatief dat ze hiervoor bieden. Aan de privacykant valt nog een hoop te klagen over facebook, maar aan de technologische kant zijn ze wel goed bezig

[Reactie gewijzigd door anargeek op 25 juli 2024 23:00]

[Thirler]

Volgens mij is dit het algemene imago van 'goed zijn voor de wereld', 100k is natuurlijk geen geld voor dit soort reclame. Daarnaast is facebook erg afhankelijk van goede browsers, omdat ze die nodig hebben voor het gebruiken van hun website.

De overhead is niet zo belangrijk, omdat deze tools niet bij normale gebruikers mee hoeven te draaien, maar alleen in sommige test versies, als je dan een beter dan gemiddelde computer neemt, merk je hier niets van.

[Iblies]

100k Is geen slecht bedrag. Je kunt er 4 hoogopgeleide mensen 4 maanden fulltime laten laten werken. Je hebt nu bijna de garantie dat je tot 2016 aan dit project kunt werken en hopelijk een aantal extra issues aan het licht brengen.

En Facebook kan zelf niet al te actief aan projecten werken waarbij zwakheden van de browsers worden blootgelegd maar zoveel mogelijk in samenwerking met externe partijen. Ze zijn afhankelijk en moeten op zoveel mogelijk platform actief kunnen zijn.

[Verwijderd]

Investeren in een goede band met een universiteit om zo knappe koppen te binden aan je bedrijf?

[_eLMo_]

Facebook's imago hangt af van het lekken van alle informatie die Facebook heeft, of dat nu lekt via hun eigen servers of via lekke browsers. Privacy garanderen is goed voor Facebook.

[PageFault]

Privacy garanderen? Volgens mij ga je, indien je akkoord gaat met het gebruik van Facebook, behoorlijk het schip in met je privacy.

Bij diensten waar je niet voor hoeft te betalen, zoals facebook, ben jij als gebruiker het product!

[Nogne]

Maar dat is dan wel je eigen keuze. Als Facebook data lekt door een bug dan kan dat aardig wat reputatie schade opleveren.

[PageFault]

Mee eens over de eigen keuze, maar niet met dat privacy garanderen goed is voor FB

Als je nooit reputatie schade wil oplopen, moet je niet aan social media doen, denk ik.

Mijn reputatie is al zo slecht, dat ik rustig op FB kan ronddwalen

[JustSomeWords]

Het probleem dat Facebook met een lek zou hebben is ook niet dat jou info bij andere mensen ligt. Maar dat zij die info niet meer kunnen verkopen

[dehardstyler]

Dat Facebook ermee aan de haal gaat, klopt. Daar ga je mee akkoord. Niet dat elke willekeurige hacker op internet mee aan de haal mag. En dat wil Facebook dan ook voorkomen lijkt mij.

[Gepetto]

Facebook en privacy in één zin LOL

[Verwijderd]

Zoals in deze blogpost lijkt het erop dat ze niet veel moeite doen. Met deze bug kunnen telefoonnummers, emailaddressen en andere via facebook afgehaald worden. In grote hoeveelheden (volledige landen) want de blogger heeft dit gedaan voor alle gebruikers in UK en Canada.
Volgens facebook is dit geen probleem. Je zou voor minder je exploits in de zwarte markt verkopen. Als je als onderzoeker telkens het deksel op je neus krijgt als je iets wilt aantonen kan ik goed geloven dat er zoveel exploits in de black market wordt verkocht.

[Reactie gewijzigd door Verwijderd op 25 juli 2024 23:00]

[MAX3400]

Facebook's imago hangt af van het lekken van alle informatie die Facebook heeft, of dat nu lekt via hun eigen servers of via lekke browsers. Privacy garanderen is goed voor Facebook.

Privacy garanderen? Dit artikel laat toch wel heel duidelijk zien dat als je gebruikt maakt van de algoritmen van Facebook en ze zijn het er niet mee eens, dat je spreekwoordelijke trap onder je kont kan krijgen en niet meer welkom bent in hun kantoren.

Daarnaast, maar ik geloof dat dat wel een algemene opvatting is: privacy is natuurlijk alleen belangrijk per bedrijf. Google zorgt voor Google, Facebook voor Facebook etc; data delen met elkaar is not done en verantwoording afleggen naar degenen wiens (meta-)data wordt gedeeld, is er al helemaal niet bij.

[[Jules]]

Breng ze nou niet op ideeen...

[croiky]

Wat Marowi zegt: imago. Ik speculeer, imago aan de voorkant en ''backdoortje'' aan de achterkant?

[Verwijderd]

Misschien wil Facebook zelf komen met een browser en zat hun prototype in de lijst van browsers die getest waren.

[Verwijderd]

Dit soort 'bugs' zijn eerder het gevolg van de manier hoe compilers uiteindelijk code produceren. Waarmee men dus eigenlijk aantoont dat een 're-invent' van compilers aan de orde is...

[Thirler]

Het is meer een 'probleem' van de taal, en niet de compilers. Bij C++ is de keuze gemaakt om veel automatische checks niet te doen. Deze keuze was voornamelijk tussen performance en kans op fouten (ookal is dit niet het enige wat mee speelde, compatibility met C, hoe veel werk het is om een compiler te maken zijn andere)

In veel moderne talen (Java/C# etc) zijn de genoemde bugs niet of minder mogelijk. In Java staat bijvoorbeeld de 'bad casting' detectie altijd automatisch aan. En door het gebruik van garbage collection is 'use after free' ook niet mogelijk.

[mashell]

In veel moderne talen (Java/C# etc) zijn de genoemde bugs niet of minder mogelijk. In Java staat bijvoorbeeld de 'bad casting' detectie altijd automatisch aan.

Nu wordt het gebruik van Java op het internet afgeraden vanwege de vele lekken. Je hebt een punt dat compilers niet alles vinden. Eigenlijk al onze klanten vereisen het gebruik van statische code checkers om die zwakten te vinden.
Ik ben bang dat het daarom ook een probleem van vooral open source is, of eigenlijk vrij beschikbare sofware is. Hier zijn de kwaliteitsnormen niet af te dwingen.

[Thirler]

Zoals hackerhater hier al zegt. Java voorkomt juist veel van dit soort veiligheidsrisico's, die C++ wel heeft. Maar het feit dat in je browser, zonder deze te controleren, allerlei software wordt/werd afgespeeld was het echte probleem (dat stelt namelijk zeer hoge eisen aan je sandbox).

Closed source zijn is trouwens niet echt een barriere voor hackers hoor. Kijk maar naar de vele fouten die in Windows gevonden worden.
Het open source zijn van populaire project zorgt er juist voor dat fouten gevonden worden, dit artikel is hier een voorbeeld van.

[mashell]

Het open source zijn van populaire project zorgt er juist voor dat fouten gevonden worden, dit artikel is hier een voorbeeld van

Alle recente SSL problemen bewijzen het tegendeel. Bij open source kan iedereen de code inzien maar ook iedereen is vrij om dat niet te doen. Het gebeurt in de praktijk dan ook niet. Deze onderzoekers hebben een runtime tool gebruikt, geen code analyse.

[hackerhater]

JAVA afgeraden wegens lekken?
De runtime in de browsers wordt afgeraden omdat het een aardige aanvals vector is en mensen het meestal niet nodig hebben.

JAVA wordt nog heel veel gebruikt, vooral op servers en op smartphones (Android).

[mashell]

Dat zeg ik toch ook? In browsers wil je het niet hebben.
Mag je zelf bedenken of het wel zo'n goed idee is om het op servers of in Android te gebruiken?

[Verwijderd]

Klopt.. Compilers beginnen ook aan het 'windows syndroom' te lijden. Ze moeten teveel 'legacy' meesleuren om 'alles' netjes te kunnen blijven compileren.

En zoals je aanhaalt zijn er bij C++ bepaalde compiler keuzes gemaakt. Dat is niet alleen bij C++ zo, maar geldt wel voor elke taal/compiler.

Het stijgende aantal exploits en 'bugs' problemen is niet alleen meer een probleem van laks geschreven code, maar begint ook duidelijk meer en meer een probleem te worden van 'laks' gecompileerde code. En daar kan de gewone programmeur weinig aan veranderen.

Mss moet 'de compiler' eens dringend 'opnieuw uitgevonden' worden...

[HerrPino]

De programmeertaal en compiler zijn niet veel te verwijten, je code moet gewoon veilig zijn. Je moet als C++ ontwikkelaar weten hoe C++ achter de schermen werkt (geldt overigens voor alle programmeertalen). Dat is ook het verschil tussen de goede programmeurs en de '13 in een dozijn' programmeurs. Als we de compiler gaan aanpassen om altijd 'veilige' code op te leveren dan gaan we enorm veel performance weggooien, ook op momenten dat die controles werkelijk compleet nutteloos zijn. Een goede code analysis en tools als dit zouden problemen als dit voor het grootste deel moeten detecteren tijdens het ontwikkelproces.

[goarilla]

Een goede code analysis en tools als dit zouden problemen als dit voor het grootste deel moeten detecteren tijdens het ontwikkelproces.

Dit leid me naar de volgende vraag: is dit nu een tool waarmee je binaries traced zoals debuggers, process monitors, valgrind, ... of een source code tool ? Jullie lijken te hinten naar het eerste maar dit is niet compleet duidelijk.

[Thirler]

quote: http://www.cc.gatech.edu/...using-new-analysis-method

CAVER is a run-time detection tool

Runtime, is dus in ieder geval geen statische source of binary inspectie (die fouten vindt zonder te de applicatie te draaien).

Vaak werken deze tools door middel van aanvullingen bij het compilen van de binaries. Bijvoorbeeld door bij iedere punt waar een claim of vrijgave van geheugen gebeurt deze te regristreren met extra infromate, deze kan dan gebruikt worden om te valideren of een operatie veilig is.

[goarilla]

Vaak werken deze tools door middel van aanvullingen bij het compilen van de binaries. Bijvoorbeeld door bij iedere punt waar een claim of vrijgave van geheugen gebeurt deze te regristreren met extra infromate, deze kan dan gebruikt worden om te valideren of een operatie veilig is.

Dus linken met wrapper libraries.

[Verwijderd]

De nieuwe compiler (infrastructuur) noemt LLVM en de compiler zelf noemt clang. Een nieuwe programmeertaal die één en ander van C++'s problemen oplost noemt D. Een aantal zaken worden ook al wel in C++11 enzo opgelost.

Ikzelf vind dat voorlopig gewoon Q_OBJECT vanboven erbij zetten en je krijgt die fameuze Q_DISABLE_COPY om copy constructors private te maken. En daarna zeg je dat QObject derived classes altijd reference types zijn. Met die afspraak los je al heel wat C++ nieuwelingen hun fouten op. Maarja, dan krijg je de RAII mannen op uw dak. Het is altijd iets in de C++ wereld. Zucht.

Het liefst van al, maar dat vind ik nu al jaren, gaan we gewoon naar D. Dat lijkt wat op Vala en C#. Maar dan zonder GObject meuk te genereren in geval van Vala en zonder Mono's VM en garbage collector die er altijd doorvliegt in geval van C# (nu D heeft wel een (optionele) GC, maar ik heb begrepen dat je die per type deterministisch kan uitschakelen, en dus gewoon nog wel delete gebruiken dan).

[EpicEraser]

Wat bedoel je hiermee?
Deze soorten bugs hebben niks met compilers te maken.

Als je in C++ (de taal waarin de kernen van beide browsers geschreven zijn) een stukje dynamisch gealloceerd geheugen dealloceert, hoor je het niet meer te gebruiken. Als je dat toch doet, gaat het mis. Dit kan niet in alle gevallen fatsoenlijk gevonden worden met statische code-analyse, dus een compiler kan hier niet altijd iets aan doen.
Bad casts komt ook gewoon door de programmeur die iets niet heeft gedaan zoals het hoort. In C++ heb je een heel aantal casting operatoren. Bij sommige heb je de garantie dat het goed gaat (onder normale omstandigheden). Als je ervoor kiest om er eentje te gebruiken die zulke garanties niet biedt, is het dus aan jezelf om ervoor te zorgen dat dit goed gaat.

Als je bedoelt dat dit soort dingen niet voor zouden moeten komen, moet je naar de taal kijken. Je zou gewoon op een wat hoger niveau kunnen gaan zitten met een taal als Java of C#. Hierin wordt (zo goed als) niet direct met geheugen gespeeld. Nadeel is dat dit een flinke impact kan hebben op performance of geheugengebruik.

[Verwijderd]

Dit hoeft geen impact te hebben op de performance of memory use van de applicatie, hardware is tegenwoordig snel genoeg dat men compilers strikter en meer solide code kan laten produceren. De 'raw' processing power is de laatste jaren zo enorm gestegen dat een 'zwaardere' compiler die meer code analyse doet om correctere code te genereren geen probleem mag vormen.

We staan ondertussen zo ver in processing power en logic dat het perfect mogelijk moet zijn dat een compiler potentiele quick & dirty source code kan herkennen en er ofwel extreme optimalisaties op toepast of simpelweg stopt met de melding dat hij die rommel niet wil of kan compileren op een deftige manier.

[EpicEraser]

Dit gebeurt ook.
De genoemde problemen zijn (wiskundig aantoonbaar) niet berekenbaar in het generieke geval. Met statische analyse is het in veel gevallen simpelweg onmogelijk om met 100% zekerheid aan te tonen dat iets niet altijd goed gaat.

Neem een invalid cast. Wat als je deze cast alleen doet als een bepaald veld een bepaalde waarde heeft? Als programmeur weet je dat deze cast geldig is wanneer dit veld deze waarde heeft, maar een compiler kan dit niet zomaar achterhalen. Een compiler zou op alle plaatsen waar dit veld deze waarde zou kunnen krijgen moeten aantonen dat als het veld de waarde krijgt, het object een instance is van de class. En wat als deze waarde het resultaat is van een complexe berekening? Ga je hem dan achteruit volgen?

Het gaat er niet om dat de code die uit de compiler komt incorrect is. Het probleem is dat de code die erin gaat incorrect is. Garbage in - garbage out. Een compiler begrijpt alleen wat jij zegt dat de code moet doen, niet wat jij eigenlijk gewild had dat de code zou doen. Zoals ik al gezegd heb, een hoger niveau taal maakt het schrijven van programma's met dit soort fouten moeilijker, maar daar staat altijd wat tegenover (performance, geheugengebruik, expressiveness, verbosity, ...).

Buiten dit hele verhaal zou je niet standaard complexe statische analyse door een compiler willen laten doen (buiten wat nodig is voor dingen als type checking en optimalisatie). Heb je enig idee hoe lang het nu al duurt om een gemiddeld software pakket te compileren?

[Schnupperpuppe]

Het heeft per definitie impact op de performance. Hoe ernstig die impact is, is een andere vraag. De simpele aanname hardware is tegenwoordig snel genoeg vind ik dan ook op zijn minst een klein beetje naïef.
De impact kan/zal in veel gevallen verwaarloosbaar zijn, maar kan in sommige gevallen ook enorm zijn.

[Niemand_Anders]

Nee, een 'use after free' bug kun je niet zomaar wijten aan een compiler. Normaal vraag je als applicatie om een stukje geheugen van het OS. Als het OS bijhoud of een bepaalde geheugen reeks nog steeds hoort bij een applicatie, kan het bij een poging naar eerder vrij gegeven geheugen te schrijven, ook gewoon de applicatie sluiten. Plop weg en eventueel een crash dump voor debugging. Met een dergelijke oplossing is het dan niet meer mogelijk om daarna 'eigen' code te injecteren omdat de applicatie niet meer draait..

[Verwijderd]

Dit klinkt mij niet als nieuw of innovatief in de oren.

Zelf heb ik begin jaren 90 voor meerdere bedrijven geheugen allocatie sub-systemen gemaakt die verkeerd gebruik van geheugen konden detecteren (ook use after free) en er bestonden ook toen al commerciële libs voor. Het is niet eens moeilijk te maken, dagen werk voor een eerste implementatie en weken om de boel optimaal en vollediger te maken.

Voor detecteren van foute casts zijn in C++ prima dynamic cast voorzieningen en voor oude manier van casting is statische analyse van code goed bruikbaar. Ook voor detectie van dit soort problemen bestaan sinds de 90s al commerciële tools, die je dan wel moet gebruiken om problemen te vinden natuurlijk.

De oplossing uit het artikel vereist natuurlijk ook een speciale browser build of een build met op zijn minst goede debug informatie. Voor gebruik zijn er geen nieuwe mogelijkheden geschapen, het niet iets wat een buitenstaander onvoorwaardelijk op een willekeurige C++ build van welke applicatie dan ook kan loslaten om bugs te vinden.

Voor mij is dit een artikel dat vooral aangeeft dat IT onderzoek en impliciet onderwijs ver achter de feiten aanhobbelt. Dat je daar dan toch 100k mee kan verdienen is dan wel weer opmerkelijk! Het probleem blijft toch dat ontwikkelaars zelf een geschikte tool moeten inzetten en kennis moeten hebben om goede code te leveren. Daar veranderd geen enkele nieuwe tool wat aan.

[Reactie gewijzigd door Verwijderd op 25 juli 2024 23:00]

[EpicEraser]

Volgens het artikel draait de tool realtime mee. Het gaat dus over dynamische analyse.
Vervolgens vindt de tool problemen.
Hoe vindt de tool deze problemen? Kijkt hij gewoon mee met normaal gebruik? Het lijkt me een beetje onzinnig om hiervoor iets nieuws te schrijven.

Dingen als use after free kunnen met een gratis tool als Valgrind eenvoudig gevonden worden in de meeste gevallen (wordt ook gedaan overigens), maar ik denk dat de situatie hier toch wat ingewikkelder ligt.

Ben wel benieuwd naar wat deze tool nu echt doet.

[Verwijderd]

Volgens een andere bron die ik heb gevonden instrumenteert het eerst de code. Conceptueel gelijk aan wat klassiek ook gedaan wordt met macro's. Op run-time doet het bepaalde analyses, maar waarom dit beter zou zijn dan meekijken met gebruik zie ik niet beschreven.

Wat ik nog kwijt wil over de performance penalty is dat die erg misleidend kunnen zijn. Voor een applicatie die alleen draait op een systeem zal het ongetwijfeld kloppen (met voldoende CPU en andere resources beschikbaar). Maar in een multitasking omgeving kan de klap vele malen erger uitvallen omdat die resource gedeeld moeten worden en er netto minder beschikbaar is. Als de set actieve code of data ineens te vaak een cache mis krijgt dan gaan de prestaties heel snel achteruit.

[Falcon]

Beste Tweakers.. waarom stoppen jullie niet wat links of achtergrond informatie over werking van dit soort bugs? Er is veel jargon te vinden in dit (korte) artikel..waar best wel wat meer over te vertellen was geweest.

/opbouwende kritiek.

[Verwijderd]

Tweakers is een site waarbij een pro-actieve houding van gebruikers wordt verwacht. Het is geen helpdesk, een vaak geschreven regel op het forum. Daarnaast beschikken mensen al over een hoop achtergrondkennis. Als je echter nog niet bekend bent met een onderwerp of er meer van wilt weten kun je dat prima zelf vinden via Google of het forum van Tweakers.

[gimbal]

Beste Falcon. Dit echt begrijpen vereist scholing en het lezen van vele technische boeken, er zijn geen online resources die je even uit het niets domeinkennis en begrip bijbrengen en daardoor vele jaren aan persoonlijke moeite ontnemen. Indien u daar niet de wilkracht voor heeft dan zult u toch echt met een half begrip moeten blijven leven.

[Falcon]

@chicaneBT en @gimbal

Niet persoonlijk gaan spelen. Natuurlijk kan ik zelf gaan zoeken, maar dat staat toch los van het feit dat Tweakers.net zelf ook een verdiepingslag kunnen doen binnen het artikel zelf? Gebeurt in andere artikelen met regelmaat wel.