Hackergruppe afslører første 0-dags sårbarhed i Firefox 3.5
Hackergruppen milw0rm har frigivet en stump Javascript-kode, der afslører en sårbarhed i den nye Mozilla Firefox 3.5.
Sårbarheden gør det muligt at afvikle ondsindet kode på den angrebne pc, og milw0rm's exploit demonstrerer sårbarheden ved at starte lommeregneren calc.exe i Windows.
Sårbarheden opstår ifølge tidsskriftet Heise Security på grund af et buffer overflow, der finder sted under behandling af særligt præparerede Font-tags. Exploitet benytter teknikken heap spraying.
Der er tale om en 0-dags sårbarhed, da Mozilla endnu ikke har lukket hullet i browseren. Ifølge Mozillas blog om sikkerhed arbejder man lige nu på et fix.
Sårbarheden kan udnyttes i den seneste version 3.5 af Firefox, og fejlen befinder sig i Firefox-komponenten Tracemonkey, der tilføjer Just-in-time native-code kompilering til Javascript-motoren Spidermonkey.
Indtil videre er der ingen forlydender om hjemmesider, der har forsøgt at benytte sig af sårbarheden.
Brugere af Firefox 3.5 kan indtil videre holde exploitet fra døren ved enten at slå JIT fra i Javascript-motoren eller installere et plug-in som for eksempel NoScript.
Ifølge Mozilla's sikkerhedsblog kan JIT slås fra ved at indtaste 'about :config' i adressefeltet, skrive 'jit' i Filter-boksen i toppen af editoren, dobbeltklikke på linjen med javascript.options.jit.content og sætte værdien til 'false'.
Se milw0rm's exploit under fanebladet Eksterne links. Artiklen indeholdt tidligere en ikke bekræftet oplysning fra det danske it-sikkerhedsfirma CSIS om, at sårbarheden også omfatter tidligere versioner af Firefox, eksv. version 3.0.11.
Kommentarer (11)
Det kunne være, at "eksperten" lige skulle læse på lektien.
JIT fandtes ikke i 3.0 - det gjorde TraceMonkey heller ikke.
Hvorfor går Version2 ikke til kilden (i begge lejre), når I skriver en nyhed?
Hvem gider at høre på en "ekspert", som åbenlyst ikke har lavet sit arbejde og for den sags skyld slet ikke er involveret.
Mozilla fortæller om sårbarheden:
http://blog.mozilla.com/security/2009/07/14/critical-javascript-vulnerab...
TraceMonkey vs SpiderMonkey:
http://weblogs.mozillazine.org/roadmap/archives/2008/08/tracemonkey_java...
-
0 -
0
Ifølge ovennævte mozilla-blog, så blev fejlen i kildeteksten faktisk opdaget og rettelsen commit'et inden milw0rm publicerede sit exploit.
https://bugzilla.mozilla.org/show_bug.cgi?id=503286
indikerer at exploitet er en omskrivning af koden, som mozilla-folkene brugte til at demonstrere deres bug. Sværere var det altså ikke...
Uanset det så går der nok ikke længe inden man kan hente sig en ny FF 3.5.
-
0
-
0
Kære læsere -
Jeg er pt. i gang med at finde ud af, hvad der er op og ned på CSIS' oplysning om, at sårbarheden også gælder visse tidligere versioner af Firefox, herunder 3.0.11.
Indtil videre har jeg dog ikke kunne bekræfte det andre steder, og derfor er teksten nu rettet til derefter.
Mvh Mikkel, version2.dk
-
0
-
0
Nu ved jeg ikke hvem der hos Mozilla kigger på dette problem, men det pågældende PoC, som er publiceret på Milw0rm.com, crasher altså vores Firefox version 3.0.11 testmaskine.
Det her ligner mest af alt en JS engine fejl, der udløses på grund af ukorrekt håndtering af escape funktionen.
Venligst
Peter
-
0
-
0
Har i puttet en debugger på FireFox så i kan se hvad der sker? (Nu er jeg jo ikke selv den aller bedste debugger, men jeg forstår da at lede efter buffer overflows i form af dem som bliver kørt direkte fra stack'en eller ved at overskrive en SEH værdi).
Det vil nok også være en god idé eventuelt at analysere "exploit"-koden :-)
-
0
-
0
Nu har Hans-Michael skrevet lidt, men nå du (Peter Kruse) skriver:
crasher altså vores Firefox version 3.0.11 testmaskine
Kunne jeg godt tænke mig at spørge om du betragter ethvert chrash som sårbarhed, eller om du er bekendt med at CPU'en skal genoptage instruktionerne ved begyndelsen af den malware (der evt. er tilkoblet).
At tro at ethvert chrash er ensbetydende med en sårbarhed er ligesom Peter og Ulven.
(Pun intended)
-
0
-
0
Jeg syntes faktisk det lå implicit i mit svar; At det ser ud til at være et problem i JS engine.
Jeg har dermed aldrig sagt at det nødvendigvis behøver at kunne køre arbitrær kode, men at det uløser en fejl i FF. Er det svært at forstå?
Venligst
Petert
-
0
-
0
At tro at ethvert chrash er ensbetydende med en sårbarhed er ligesom Peter og Ulven. (Pun intended)
Ethvert crash der kan udløses udefra, er en potentiel sårbarhed (og til en vis grad en Denial-of-Service sårbarhed i sig selv). At gå ud fra andet uden at have undersøgt det til bunds, er relativt tåbeligt.
- Og at samme kode kan crashe en tidligere udgave, tyder på at det er exploitable på samme måde.
-
0
-
0
Sårbarheden gør det muligt at afvikle ondsindet kode på den angrebne pc, og milw0rm's exploit demonstrerer sårbarheden ved at starte lommeregneren calc.exe i Windows.
Det er ikke umiddelbart til at overskue, men gælder denne sårbarhed på alle platforme, eller er det kun Windows som nævnt i eksemplet?
/Christian
-
0
-
0
uvildig undersøgelse og sammenligning af sikkerheden imellem IE, FF, Chrome og Safari (som udgangspunkt).
Også gerne en statistik over sårbarheder, som er blevet udnyttet.
Mht. det første, har jeg fundet pwn2own, en hacker (egentlig cracker)-contest, hvor det gælder om at overtage en maskine på baggrund af exploits.
http://www.paulspoerry.com/2009/03/19/pwn2own-hacking-competition-all-br...
Den viser iøvrigt, hvad enhver nok ved, at alle browsere har sårbarheder (omend Chrome er ret sikker åbenbart). Men jeg savner mere statistik og egentlig viden/kolde fakta.
Helst samlet, så det er let at sammenligne.
PS: Og hvad bliver der af Opera. Hvorfor hører man ikke mere om sårbarheder der - er den så god?
-
0
-
0
Tilføj kommentar
