Firefox, Edge en Safari vallen ten prooi aan Pwn2Own-hackers

Tijdens het Pwn2Own 2018-evenement zijn beveiligingsdeskundigen erin geslaagd nieuwe kwetsbaarheden in de browsers Firefox, Edge en Safari uit te buiten. Daarmee wisten ze 267.000 dollar van de prijzenpot van 2 miljoen dollar binnen te slepen.

Woensdag demonstreerde onderzoeker Richard Zhu, alias fluorescence, een sandbox escape voor Safari, maar hij kreeg zijn exploit niet werkend binnen de gestelde tijd van dertig minuten. Meer succes had hij bij een poging om Edge te kraken, met behulp van een use-after-free-kwetsbaarheid in combinatie met een integer overflow in de kernel. Safari viel later alsnog ten prooi op de eerste Pwn2Own-dag, via een combinatie van een JIT-optimalisatiebug, een macOS-kwetsbaarheid om de sandbox te verlaten en kernel-overwrite. Hacker Samuel Groß liet daarop een 'pwned'-tekst op de Touch Bar van de MacBook Pro verschijnen.

Donderdag was het opnieuw Zhu die ditmaal Firefox kraakte met een out-of-bounds-kwetsbaarheid gevolgd door een integer overflow via een kernelbug in Windows om uit de sandbox te geraken. Drie hackers slaagden er daarna in om Safari opnieuw met succes aan te vallen. Dat lukte pas bij de vierde poging, waar slechts drie pogingen toegestaan zijn. Een ander team, van MWR labs, lukte het vervolgens alsnog om reglementair Safari te hacken, via een heap buffer overflow en een uninitialized stack variable in macOS.

Zhu mocht zich uiteindelijk met twaalf punten en 12.000 dollar aan prijzengeld Master of Pwn noemen. De wedstrijd wordt jaarlijks gehouden door Trend Micro's Zero Day Initiative, dat betaalt voor de kwetsbaarheden en deze doorspeelt naar het betreffende softwarebedrijf, dat negentig dagen krijgt om deze te patchen.

Opvallend was dit jaar dat Chinese onderzoekers zich terugtrokken, nadat de Chinese overheid had aangegeven niet te willen dat ze kwetsbaarheden via derde partijen buiten China deelden, schrijft Bleeping Computer. China wil dat de onderzoekers zich direct tot de leverancier wenden. In voorgaande jaren wonnen Chinese deelnemers regelmatig.

Reacties (65)

In programma's die zoveel functionaliteit aanbieden, cross platform zijn en dus veel complexiteit bevatten zullen er nog vele bugs/exploits verscholen zitten. Maar het is toch wel straf dat tijdens de duur van het evenement in de 3 browsers een exploit is gevonden.

Voor veel (alle?) exploits die hier gevonden worden zal niet gelden dat er pas tijdens het evenement naar gezocht wordt. Veel deelnemers gaan naar Pown2Own met een reeks aan vulnerabilities die ze in de voorgaande maanden hebben opgespaard. Er is altijd het risico dat je niet de enige bent die de zelfde vuln. hebt gevonden en er is een groot risico dat een vuln gepatcht wordt voordat je hem hebt kunnen demonstreren dus je moet er een paar opsparen om redelijke kans te maken.

Als er dus tijden genoemd worden ("binnen twee seconden gekraakt" of "drie pogingen binnen een half uur") gaat het niet om het vinden van de exploit maar om het uitvoeren.

is het niet een beetje raar dat je exploits voor je houdt dan voor die periode... misschien dat jij goeie bedoelingen hebt, maar potentiele gaten open laten zodat je een wedstrijd kunt winnen is misschien op z'n minst twijfelachtig?

Het alternatief is dat mensen niet meer op zoek gaan naar deze exploits omdat er geen beloning aan hangt. Of ze het vroegtijdig melden of niet, die exploits zitten er toch wel.

[Reactie gewijzigd door Bonobo op 16 maart 2018 21:26]

Of ze worden verkocht aan criminelen die er dan wel voor willen betalen.

Zero day exploits zijn heel erg veel geld waard inderdaad.

Voor 12.000 euro verdwijnt dat twijfelachtige bij mij erg snel.
Zoals een bepaalde supermarkt keten adverteert “HAMSTERUUUUUHHH”

Tja winnaarsmentaliteit :-) Maar goed, er is nu dan toch minstens een keer per jaar dat er weer een batch aan gaten gepatcht kan worden, terwijl die zonder de wedstrijd wellicht veel langer onder de radar zouden kunnen blijven.

Net zo twijfelachtig dat jou brouwser nog tientale gaten open heeft die nog ontdekt moeten worden...

Een webbrowser is verschrikkelijk complex, vergelijkbaar met een compleet besturingssysteem, en misschien nog wel complexer. Het is niet voor niets dat veel browsers nog gebaseerd zijn op code van meer dan 20 jaar geleden. Het is bijna ondoenlijk om een webbrowser vanaf scratch te schrijven.

Vandaar dat er ook zoveel fouten in worden gevonden. Het is daarom toe te juichen dat fabrikanten zoals Mozilla overschakelen naar een computertaal (Rust) die memory en thread-safe is.

Wat ik ook graag zou zien is unit-testing in webbrowsers. Ik kan mij voorstellen dat de meeste browsers duizenden unit tests moeten draaien om aan te tonen dat de code goed werkt.

[Reactie gewijzigd door ArtGod op 16 maart 2018 14:17]

Het is bijna ondoenlijk om een webbrowser vanaf scratch te schrijven.

Bijna, maar Mozilla's experimentele Servo browser is in feite een rewrite-from-scratch, en komt héél goed in de buurt van een echte webbrowser. Al is het niet per se de bedoeling dat Servo effectief een volwaardige webbrowser wordt. Mozilla heeft er nl. al zo één: Firefox. Onderdelen van Servo (d.w.z., de in Rust geschreven code waar je naar verwijst) worden stukje voor stukje in Firefox geïntegreerd, wanneer blijkt dat ze goed werken in Servo. Dit heet dan Project Quantum, en is de reden waarom Firefox 57 ook "Quantum" genoemd werd.

Edit: oh, blijkbaar werken links niet [zo](https://url) hier.

[Reactie gewijzigd door M0N0 op 16 maart 2018 14:26]

Nee, helaas werken links niet zo. Vroegâh heeft Tweakels het RML-dialect in gebruik genomen, en dat maakt de omschakeling naar Markdown lastig. Laat staan de custom tags die Tweakers nog gebruikt.

RML? RDF mapping language? http://rml.io/spec.html

React Markup Language, zo te zien

Servo is echter sinds 2013 in ontwikkeling maar is nog lang niet bruikbaar als een echte browser. Dit terwijl ze niet alles hebben herschreven. De Javascript engine is bijvoorbeeld hetzelfde als in Firefox. Browsers schrijf je niet even in een paar jaar.

Browsers schrijf je niet even in een paar jaar.

Dat kan zeker wel als je er maar genoeg geld voor over hebt / prioriteit op zet

Kijk naar Google.

Een browser is een van de hoofdaders van hun onderneming. Geld is daar ook minder een issue.

Zij hebben ook geen alternatief waar ze op terugvallen.
Ze zijn er zelfs niet fatsoenlijk mee bezig.

Samsung is bezig met servo meer uit noodzaak.

MS heeft dat met Edge echter wel gedaan.

Sterker nog, als je een browser te lang door-evolueert krijg je mensen die (al dan niet terecht) een afkeer krijgen van hun eigen code (denk aan Opera/Presto). In plaats van refactoring is herschrijven of inkopen van code dan opeens een economische optie.

[Reactie gewijzigd door mae-t.net op 19 maart 2018 04:13]

En toch doet het uiterlijk van webbrowsers niet vermoeden dat ze zo complex zijn.

Wat ik ook graag zou zien is unit-testing in webbrowsers. Ik kan mij voorstellen dat de meeste browsers duizenden unit tests moeten draaien om aan te tonen dat de code goed werkt.

Wat bedoel je precies, of browsers tests hebben? Ja, vb: https://chromium.googleso...ess_render_browsertest.cc

En of je de browsers kunt gebruiken om tests te draaien? Ja, vb: https://jasmine.github.io

[Reactie gewijzigd door Ed Vertijsment op 16 maart 2018 14:30]

Wat ik ook graag zou zien is unit-testing in webbrowsers.

Testen kunnen we wel . Een recente test-run voor een Chrome voor Windows build geeft me de volgende nummers:

• 11,483 integratietests
• 92,743+ unit-tests
• 75,059 layout tests

Hier zitten platform-specifieke tests voor Windows bij, maar niet die van andere platformen—Chrome ondersteunt zes platformen: Windows, Mac OS, Linux, Android, iOS en Chrome OS. Daarnaast draaien alle tests in zowel Release als Debug builds, voor 32/64 bits en met talloze analyse tools zoals MSan, LSan, TSan etcetera.

Op deze pagina kan je een overzicht met een subset aan onze infrastructuur zien.

Zou je een beetje simpel kunnen uitleggen wat het dan mogelijk complexer maakt dan een OS? En browsers zoals Chrome en Opera zijn toch gebaseerd op Chromium en dat bestaat toch pas sinds 2008 ofzo?
(Ik heb geen bal verstand van programmeren)

De HTML specificaties die een browser moet verwerken zijn enorm groot. Daarnaast heb je nog de layout die ook heel complex is. Dan heb je nog Javascript en de DOM die je moet implementeren. Dan heb je nog de UI en plugin / add-on interfaces.

Daarnaast komen er steeds nieuwe standaarden bij die je moet implementeren zoals HTML Video, Websockets, WebGL en Encrypted Media Extensions.

Gebruikers hebben ook hoge verwachtingen wat betreft performance omdat veel webapplicaties zwaar zijn (zoals Facebook). Er moet dus veel performance optimization plaatsvinden.

[Reactie gewijzigd door ArtGod op 17 maart 2018 13:54]

Maar alles wat de browser moet verwerken gaat toch via het 'OS' of praat de browser rechtstreeks tegen de hardware?

Een OS beheert alleen toegang tot geheugen, processen en hardware. Het 'verwerken' zoals jij het noemt gebeurt door de programma code van de browser.

It is eenvoudig om in c/c++ code te maken die tread-safe is. Het is echter wel moeilijk om dat een beetje performant te houden...

Ik vermoed dat ze al wisten wat ze gingen doen want je "ontdekt" niet zomaar een bug in 30 min. Zoeken

Dit zijn niet allemaal direct browser exploits, aantal zijn ook vanuit OS aanvallen (dus juist vanaf de achterkant ipv voorkant).

Secondair mochten ze ook gebruik maken van bestaande bugs:
he used two use-after-free (UAF) bugs in the browser

Even voor de duidelijkheid UAF zijn niet persé reeds bekende bugs.

Volgens mij nemen ze hun exploit al mee daarheen en hoeven ze het alleen maar te demonstreren op een "echte" computer om te laten zien dat het daadwerkelijk werkt. 30 minuten is veel te weinig om exploits in te vinden. Als ze zo makkelijk te vinden waren, werden die bugs allang al misbruikt door kwaadwillenden.

Je kunt dus nu al beginnen met het zoeken naar bugs en als je iets vind wachten tot volgend jaar om er geld mee te verdienen. $70.000 lijkt me niet slecht als jaarinkomen. Moet je alleen wel iets kunnen vinden dat ook nog werkt tegen die tijd, want anders verdien je helemaal niets

Maar het is toch wel straf dat tijdens de duur van het evenement in de 3 browsers een exploit is gevonden.

Het zijn voorbereide exploits. Het is niet alsof ze ter plekke eens kijken of er nog een zwakte in zit. De research is doorgaans al van te voren gedaan.

Het evenement geeft ze een aantal rondes van 30 minuten de tijd om te demonstreren wat ze hebben uitgeplozen.

Maar zoals met iedere demo, soms heb je ergens geen rekening mee gehouden als je op niet-eigen apparatuur draait. Vandaar dat soms ook dingen wel/niet lukken.

[Reactie gewijzigd door Keypunchie op 16 maart 2018 15:06]

De meeste kwetsbaarheden hier probeert Mozilla op te lossen door hun programmeertaal Rust. Een aantal componenten zoals het style component en het toekomstige render component zijn hierin geschreven.

[Reactie gewijzigd door NiLSPACE op 16 maart 2018 14:13]

En hoe draagt Rust hier aan bij?

Zie https://www.rust-lang.org/en-US/ voor info.

Kort door de bocht: Rust biedt garanties m.b.t. memory en thread safety.

Klassieke programmeertalen als C en varianten zijn snel omdat ze volledig gestript zijn van beveiliging. Moderne talen hebben vele vormen van beveiliging ten koste van de performance. Rust is een taal dat vele vormen van beveiliging biedt en standaard aan heeft staan, maar je wel de mogelijkheid geeft om snelle, onbeveiligde operaties te doen.

Applicaties geschreven in Rust zullen dus standaard "veiliger" zijn, maar performance-kritieke delen kunnen alsnog met bijna identieke performance geschreven worden.

Disclaimer: Dit bericht bevat mogelijk misleidende waarheden om de uitleg simpel te houden.

[Reactie gewijzigd door Gamebuster op 16 maart 2018 14:39]

Gestript ? zat er gewoon nooit in.
kernighan ritchie manual http://cs.indstate.edu/~c...rogramming_language_2.pdf

Ik had zo'n mooie disclaimer eronder gezet

Handig als je die gebruikt

C laat je eigenlijk door heel het geheugen schrijven tenzij je zelf bijhoudt of je buffer al op is en andere checks doet. Dus een array met een capaciteit van 8 bytes laat gewoon een 9de toe en dat wordt dan gewoon doorgeschreven, net alsof je in machinetaal een rijtje van de zelfde data wegschrijft. Dan ga je dus over andere data heen schrijven.

Stel je voor dat je in je geheugen eerst een 8 bytes met je username hebt en daarna een bit die aangeeft of je admin bent, maar je checkt niet of iemand toevallig 9 karakters of meer stuurt als username. Stel dan dat je als username "henkiehe1" gebruikt dan wordt er in het stuk geheugen voor je username "henkiehe" geschreven en naar het stukje geheugen waar isAdmin staat de waarde 1, oftewel true.

In werkelijkheid zit het (tegenwoordig) ook onder C veel ingewikkelder in elkaar dan dat maar buffer overflows zijn wel nog steeds veel gebruikte aanvallen.

Rust is pretty much C-level performance, met memory/concurrency garanties, en de filosofie dat abstractie geen performance hoeft te kosten.

Maar is Chrome dan niet getest? Of vonden ze geen kwetsbaarheden?

Volgens de pagina van het evenement waren er ook prijzen voor Chrome:
$60,000 voor een Sandbox Escape en $70,000 voor een Windows Kernel Escalation of Privilege.

Het lijkt er op dat deze prijzen niet zijn uitgekeerd, simpelweg omdat het (binnen de voorwaarden) niet gelukt is om deze doelen te bereiken.

Wel raar dat daar nergens (ook niet in blog van trend micro) melding wordt gemaakt dat er voor Chrome geen exploits waren gevonden. Misschien dat de delegatie van China op Chrome was gericht?

Wel raar dat daar nergens (ook niet in blog van trend micro) melding wordt gemaakt dat er voor Chrome geen exploits waren gevonden. Misschien dat de delegatie van China op Chrome was gericht?

Die waren er wel, maar konden niet binnen de reguliere tijd/pogingen worden gedaan. Dus worden niet vermeld. Hieruit kan je dus niet concluderen dat er geen exploit voor Chrome was.

Of , heel negatief gesteld, omdat er in de echte wereld meer geld mee is te verdienen......

In het gelinkte artikel wordt Chrome ook niet genoemd, dus ik vermoed dat dit geen doelwit van de deelnemers was.

Ben ik ook wel benieuwd naar

Richard returned to target Microsoft Edge with a Windows kernel EoP, and he brought a flair for the dramatic with him. After his first attempt failed, he proceeded to debug his exploit in front of the crowd while still on the clock. His second attempt nearly succeeded, but the target blue screened just as his shell started. His third attempt succeeded with only one minute and 37 seconds left

Alsof je een spectaculaire voetbalwedstrijd volgt, mooi beschreven hoe hem het lukte

Werken deze exploits niet op Google Chrome dan?

Nee, exploits zijn heel specifiek voor één browser, soms zelfs voor een bepaalde versie op een bepaald platform.

Ja en nee. Er zijn vast ook wel exploits die zich op de rendering engine richten. Het kan dan zomaar dat er een handvol browsers kwetsbaar is; zoveel verschillende rendering engines zijn er immers niet.

Correct me if I am wrong maar dit zijn toch in principe juist bugs in de betreffende besturingssystemen? Uiteraard benaderd via de browser. Als een programma met standaard rechten zich, buiten de regels om, administrator rechten kan geven dan gaat degene die de regels handhaaft, hier het OS, in de fout.

Er is in de voorbeelden sprake van exploits die eerst uit de sandbox van de browser breken voor ze het os aan (kunnen) vallen.

"Rechtstreeks tot de leverancier wenden"

Uhuh. Rechtstreeks aan Peking geven zullen ze bedoelen.

Edit: typo

[Reactie gewijzigd door STFU op 16 maart 2018 14:44]

De leverancier van hun salaris dus...

Dat zou best eens kunnen ja.

Hoezo is dit vreemd, niemand kan garanties geven dat de tussenpersoon niet gecompromiteerd is. (Bijv. zijn salaris van een inlichtingendienst ontvangt)

Edit: autocorrect fail

[Reactie gewijzigd door twizzle op 16 maart 2018 23:49]

waarom zou de tussenpersoon in elkaar gedrukt zijn?

Oopsie gecompromiteerd inderdaad, maar mijn telfoon vind gecomprimeerd mooier

Ik vermoed dat de Chinese overheid naar hen heeft gecommuniceerd dat ze alle exploits aan hen moeten doorgeven. Voor de buitenlandse pers wordt geroepen dat het rechtstreeks naar de fabrikant moet worden doorgegeven.

Precies dat vermoed ik ook. Echter aan de moderatie te zien, vinden onze medetweakers dat een ongewenste opmerking

Is het niet zo dat Google zelf een veel hoger geld bedrag uitkeert bij het hacken van Chrome?

Waarom zou je het dan 'opsparen' voor een evenement als dit, met als gevaar dat het lek al gedicht is t.z.t., of vele anderen het ook al gevonden hebben en je dus het geld bedrag aan je voorbij ziet gaan? Of mis ik iets..

[Reactie gewijzigd door DutchKevv op 16 maart 2018 15:17]

Jongens, ik weet het, je houdt van vulgaire meisjes
Hoe zit het met online-communicatie met hen zonder grenzen? Hier http://datememan.ru kun je geile echte meisjes uit verschillende landen vinden.

Donderdag was het opnieuw Zhu die ditmaal Firefox kraakte met een out-of-bounds-kwetsbaarheid gevolgd door een integer overflow via een kernelbug in Windows om uit de sandbox te geraken.

Feitelijk is Windows dus de boosdoener. In Linux zou deze exploit dan niet werken.

Ongeacht wat er onder Linux gebeurt (bijvoorbeeld: FF crasht maar de exploit werkt niet) is de exploit onder Windows mogelijk door een fatale opeenstapeling van minstens 2 fouten waarvan 1 in Firefox en 1 in Windows.