"Bocs Google ... de megtörtük a Chrome-ot és a sandbox-át"

A VUPEN tegnap bejelentette, hogy egy kifinomult exploit segítségével sikerült megtörni Windows-on az ASLR/DEP/Sandbox biztonsági mechanizmusok ellenére a Google Chrome-ot. Az exploit az összes Windows (32 és 64 bit) verzión működik. Az alábbi videó Microsoft Windows 7 SP1-en (x64) futó 11.0.696.65-ös Google Chrome-on mutatja be az exploit-ot működés közben:

Hozzászólások

This code and the technical details of the underlying vulnerabilities will not be publicly disclosed. They are shared exclusively with our Government customers as part of our vulnerability research services.

… remélem, azért úgy mellékesen a Google-nek is szóltak… ☺

int getRandomNumber() { return 4; }  // ← aláírás
//szabályos kockadobással választva. garantáltan véletlenszerű.  xkcd

Végre meg lehet nyitni webes felületről natív windowsos alkalmazásokat Chromeban is!

Na ezért kérdezem, mert a chrome két módszert használ AFAIK. Az egyik egy saját sandbox implementáció a saját sandbox-ot nem tartalmazó rendszereknél (XP, binugz), a másik meg egy wrapper a vista/win7 sandbox implementációhoz. Így gyakorlatilag megtörték a chrome-ot és a vista/win7 párost is. Ja igaz, akkor a saját sandbox is elhullott, ha XP alatt is megtörték.

Nagyon praktikus. Olyat változatot esetleg lehetne belőle kérni, hogy amikor reggel megnyitom a hupot, akkor indítsa el az Eclipse-et és az Outlookot?

L0L, ez most mi?! Megnyitja a calc.exe-t és szenzáció?! :O

Persze. Ez az eszkoz a kovetkezo szintre emeli a how-to-k egy uj fajtajat. Linkre kattintva meg is csinalja szamodra a leirtakat, nemcsak szajba ragja. Kepzeljuk el milyen kiraly lesz a kovetkezo btrfs how-to, csak raboksz a leiras vegen a "Do it!" gombra es rogton eloall egy btrfs-re formazott vinyo. Mit nekunk informacio megosztas...

---
pontscho / fresh!mindworkz

2 dolog miatt nagy szam ez a bejelentes.
egyreszt tetszoleges kodfuttatast sikerult elerni a browserbol egy preparalt website meglatogatasaval, masreszt pedig ezt nem fogta meg a sandbox:
http://www.chromium.org/developers/design-documents/sandbox/Sandbox-FAQ
"What does and doesn't it protect against?

The sandbox limits the severity of bugs in code running inside the sandbox. Such bugs cannot install persistent malware in the user's account (because writing to the filesystem is banned). Such bugs also cannot read and steal arbitrary files from the user's machine."

az gondolom nyilvanvalo, hogy onnantol kezdve, hogy kulso processzt el tudott inditani, barmit el tudott volna inditani (najo, nem egeszen, a calc.exe rajta van az UAC kivetel listan asszem)

Tyrael

erre gondoltam:
http://www.opensc.ws/snippets-unsorted/9449-windows-7-uac-bypass-proof-…
"Programs on this second list are able, without being elevated themselves, to create certain elevated COM objects without triggering a UAC prompt. Once such an object has been created the processes can then tell it to perform actions which require administrator rights, such as copying files to System32 or Program Files.
This appears to be a superset of the first list. In fact, it seems to include all executables which come with Windows 7 and have a Microsoft authenticode certificate."

Tyrael

a végén kiderül, hogy antivirtel-nek lesz igaza... s egy kamu volt az egész videó...beállítottak a calc.exe -re, egy gyorsbillentyűt, majd amikor betöltött az "exploit" oldal megnyomták...

na jó lehet, hogy a hírnevét ennyire nem járatja le egy "Sec" cég...

Nem csak, és valóban nem is csak a Google játszotta meg a verseny előtt 2 nappal a frissítést, hanem a Mozilla is. Épp ezért nem túl meglepő, hogy ennek a két cégnek maradt csak talpon a böngészője, mert a versenyre nevezők nem készültek arra, hogy menet közben megváltozik a célpont. Épp ezért nem jelentek meg a jelentkezők végül a rendezvényen. A kérdés már csak az, hogy ettől biztonságosabbnak nevezhetők-e ezek a böngészők.

Tűnhet így is. A valóság viszont inkább az, hogy a jelentkezők nem stabil és megbízható exploitokkal indultak a versenynek (mivel azok kifejlesztése nagyságrendekkel több idő és pénz, ezért más a célpiacuk is [értsd: nem pwn2own játékon fogják elpuffogtatni aprópénzért, hanem jobban fizető ügyfélnek adják el, pl. kormányzati intézménynek, lásd jelenlegi hír]), így ha a gyártók nem javítottak volna a hibákat, hanem csak egyszerűen újrafordítják a böngészőket más beállításokkal (más paraméterekkel, más fordító optimalizációval, stb.), akkor is meggátolták volna az érintett sebezhetőségek kihasználását kódvégrehajtásra és homokozóból való kitörésre...

Úgyhogy a Google és a Mozilla nem ügyes volt és gyors, hanem szimplán gecik voltak, mert tudták, hogy ezzel keresztbe tesznek a versenyzők sikeres próbálkozásainak, így jobban mutatnak majd a hírekben, hogy talpon maradtak a termékeik. Csak ettől még nem lesznek a valóságban biztonságosabbak, ez csak hamis biztonságérzetet ad egyeseknek.

Tehát, akkor egyetértünk abban, hogy valós hibajavítások történtek a két cég részéről. Szerintem ez jó. Más cég részéről pedig nem történt ilyesmi. Ami szerintem nem annyira jó. Visszatérve oda, hogy a hibajavítás (pláne ha kritikus) annál jobb, minél előbb érkezik.

Értem én, hogy miről beszélsz. Neked nem tetszik az időzítés. Akár egyet is érthetek vele.

De véleményem szerint még mindig jobb a versenyre rákészülve 10 hibát kijavítani, mint nem tenni semmit.

--
trey @ gépház

Nem feltétlen sportszerűtlen. Egyszerűen az is lehet, hogy a cégen belül kihirdetésre került, hogy "gyerekek, jön a verseny, húzzunk bele, zárjunk le annyi hibajegyet, amennyit lehet".

Ha már sport... "Srácok, itt az olimpia, kapjátok össze magatokat, adjatok bele mindent, mutassuk meg nekik."

Ha így van, ez szerintem nem sportszerűtlen.

--
trey @ gépház

Az egyszerű, verseny előtti frissítéssel nem valódi biztonságot hoznak be a cégek, csak a termékeik jó hírét védik meg azzal, hogy nem lesz sikeres a _versenyen_ a sebezhetőségek kihasználása. A valóságban ugyebár nem csak egy napig lehet próbálkozni egy biztonsági hiba kihasználásával...

De lásd Sam Thomas esetét, akinek a 0day hibáját nem javította a Mozilla a Firefoxban, tehát továbbra is kihasználható volt az, csak mivel megváltoztak a frissítés következtében a binárisok és ezáltal a memory layout is, ezért az előző verzióra készített exploitja nem tudott kódvégrehajtást elérni, "csak" elcrashelt tőle a böngésző.

Ettől még a sebezhetőség továbbra is jelen van, a Firefox nem lesz biztonságos, csak kicsit többet kell dolgozni az exploiton, hogy az új verzión is működjön a kódvégrehajtás...

Chrome Stable Releases:


 January 12 -  8.0.552.237
February 03 -  9.0.597.84
February 08 -  9.0.597.94
February 10 -  9.0.597.98 
February 28 -  9.0.597.107 
   March 08 - 10.0.648.127
   March 09 - PWN2OWN

A vak is láthatja, hogy nem valami kis minor fixek történtek, hanem egy előrehozott major verzióugrás...

Volt a 2 héttel fagyasztott verzió és az aktuális. Előbbieket nem díjazta pénzösszeggel a TippingPoint (mínusz $15,000), így értelemszerűen nem lőtte el senki se rá a 0day exploitját, hacsak nem lehetett biztosan tudni, hogy az aktuálison is működik, mint a Safari esetében...

reminder

"A valóságban ugyebár nem csak egy napig lehet próbálkozni egy biztonsági hiba kihasználásával..."

hát ez az! tudtommal a versenyzők is 1 évig készülhetnek, hogy learassák a babérokat. nehogy már ennyire alájuk tegyék a széket, hogy nehogy javítsunk sec hole-t, mert szegények nem tudnak nyerni. pont erről szólna a verseny, nem? hogy a gyártó minden erőfeszítése ellenére is bejutnak a versenyzők.

az upstream meg hülye lenne nem javítani amit tud. 2 versenyzőnél egyiktől elvárni hogy ne saját érdekeket nézzen, az érthetetlen. a többi böngésző gyártó volt hülye ha volt a kezükben ismert hiba és nem tették be a fix-et imho.

Nem tudom eldönteni, hogy én írok ennyire érthetetlenül vagy ti nem olvassátok el, amit írok... Leírom mégegyszer, hátha talán majd most sikerül eljutnia az információnak az agyig:

A Firefox esetében konkrétan biztosan nem javították a hibát. Az hogy nem sikerült kihasználni, _nem_ a böngészőnek vagy a vendornak az érdeme.

0 day exploitokrol beszelunk. A szerzon kivul senki se tudja (vagyis nem sokan ha meg nem publikalta).
Itt a lenyeg azon van, hogy ezek az exploitok specialisan az adott bongeszo tamadasara lettek kitalalva (mivel meg van adva az arch, az op, a szoftver verzio). Igy egy uj verzioval, de eleg csak egy uj build-et csinalni mas beallitasokkal, a memory layout cserelodik (pl a kulonbozo fvgk belepesi pontja).
Igy az exploitod helybol nem fog mukodni vagy szimplan crasheli a bongeszot a corrupt injecting vagy ugras miatt.

Verseny valojaban nem arrol szolt, hogy 2 napon belul ujra meg kell talalni ? :)
Az ember azt hinne, hogy 2 nap nagy ido erre, es a kedves vadaszoknak scriptjei vannak amik talalnak (de lagalabb sokat segitenek).

A mondataidbol azt is konyen ki lehetne olvasni, hogy tobbet jelent, ha valaki forrasbol tesz fel valamit mintha a vendor foltozna...

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

A különbség az, hogy nem a böngészők versenyeznek, hanem a böngészőkön versenyeznek a hackerek.

A snooker jó példa, a böngésző az asztal, a golyók, a dákó, a játékos a hacker. Ha megváltoztatod az eszközöket, azzal a játékos taktikáját teljesen alááshatod, ezzel befolyásolva a játék végeredményét. A cél ugyanis az lenne, hogy egyrészt kiderüljön, ki tud jobban játszani, másrészt hogy melyek a jobb eszközök, ez pedig csak akkor lehet, ha hagysz időt a játékosnak a gyakorlásra az eszközökkel.

--
Don't be an Ubuntard!

Engem, akit nem igazán érdekel a verseny eredménye, az izgat, hogy minél előbb kijavítsák a hibát és nem az, hogy Gipsz Jakab hacker nyerjen x ezer dollárt a versenyen azzal, hogy rajta ül egy bugon és azért szurkol, hogy a versenyig azt nehogy kijavítsák, vagy bármit módosítsanak, hogy működjön a megoldása. A versenykiírásban nincs olyan kitétel tudtommal, hogy a versenyig nem lehet javítani, így sportszerűtlenségre - amit egyébként sem tudok itt értelmezni - hivatkozni szerintem felesleges. Tessék beleírni a versenykiírásba (ilyet sosem fognak, mert whitehat security ember sose kérne ilyet), hogy a verseny előtt már 2 héttel nem lehet frissíteni.

--
trey @ gépház

Nem azon rugozik, h visszakellene tartania a fixeket, hanem h tisztessegtelen ilyen modon reklamozni valamit ahogy a google ill. a mozilla tette. Mert a sajtoban az a mantra van, h a firefox es a chrome az mekkora jo, mert feltorhetetlen, kozben meg nem is, csak trukkoztek a vendorok. Mint anno az nvidia a 3dmark-kal.

---
pontscho / fresh!mindworkz

eleve nem csak olyan exploit-tokkal készülnek a versenyzők, amelyekhez a kihasználandó hibákat csak ők ismerik? azt hittem miller-ék is a saját maguk által felfedezett sebezhetőségeket használják ki, amelyeket nem publikálnak a versenyig. ha így lenne, akkor alig tudna az upstream javítani verseny előtt 1-2 nappal.

Lehet, hogy szerinted vicces, szerintem viszont sportszerűtlen...

Biztos lehet jobb példát is hozni, de az asztaliteniszben is a játékszabályok megsértését súrolja, ha verseny előtt megváltoztatják a kiírást, hogy milyen márkájú/típusú labdával lesznek a mérkőzések.

A 2000-es olimpiai játékok kapcsán pl. a kínaiak jogosan voltak felháborodva, hogy a korábban használt 38 mm labdákat felváltották jóval lassabb 2.7 grammos, 40 mm labdákra, mert ezzel megnehezítették a kínai játékosok gyors, támadó stílusát.

ahogy trey-jel mar megbeszeltetek, ezek valos hibajavitasok voltak.
latni kell, hogy az egesz verseny arrol szol, hogy a vendorokat ravegyek arra, hogy vegyek komolyan a biztonsagot.
csinaltak neki nagy nyilvanossagot, es nemi dijazast (a dij a 0-day feketepiaci arakhoz kepest lofutty, szoval kb. ) ami talan a kiutazas koltseget fedezi az induloknak, de ok is inkabb csak jofejsegbol meg a hirnevert vesznek reszt.

szoval az hogy a vendor javitja a hibakat (es a verseny kozeledtevel meg inkabb) az nem sportszerutlenseg, hanem pont hogy a kivant eredmeny a szervezok szemszogebol.

szerintem.

az, hogy szerinted a pwn2own nem jol tukrozi a resztvevok kozti helyzetet, mert 1 hettel a verseny elott, vagy utan teljesen mas eredmenyek szuletnenek, az valamilyen szempontbol erheto.
de egyreszt minden vendor elott ott a lehetoseg hogy a verseny elott fixelje az ismert hibakat(es aki nem el vele, az lehet hogy altalanossagban sem veszi eleg komolyan a biztonsagi hibak javitasat), masreszt pedig a versenynek nem az a celja, hogy aktualis kepet nyujtson a vendorok kozti viszonyokrol, hanem hogy ezzel az uruggyel ravegye oket a frissitesre.

Tyrael

Én nem tudom honnan veszed ezt, hogy a pwn2own arról szól hogy a vendorokat rávegyék a frissítésre...

Ezek a trükközések ráadásul kifejezetten károsak hosszútávon az érintett szoftverek biztonságára, mert így a jelentkezők be fognak inteni a szervezőknek és a vendoroknak, aztán a publikálás helyett inkább eladják az exploitjaikat a fekete, vagy a "szürke" piacon.

Eddig is csak azért voltak résztvevők, mert a hírnévkeltés kompenzálta az egyébként csekély jutalmazást. Ha az ilyen jellegű, verseny előtti frissítésekkel nehezítik meg a gyártók a sebezhetőségek kihasználását és nem valódi biztonsági megoldásokkal, meg prevenciós technikák kifejlesztésével érik el, hogy a hibák kihasználhatatlanok legyenek, akkor ez csak egy hamis biztonságérzetet adó marketingforrássá válik... Lásd: "senki se tudta feltörni" vs. "senki se próbálta feltörni". Aztán majd ott leszünk, hogy pwn2own vetélkedőn talpon marad mindegyik böngésző ("hú de biztonságos már minden"), a valóságban meg továbbra is kihasználják a sebezhetőségeket a megfelelően értékes célpontokon.

http://googlechromereleases.blogspot.com/2011/03/beta-channel-update_03…
http://googlechromereleases.blogspot.com/2011/03/chrome-stable-release…

11-es verzional meg kevesebb ido telt el az utolso beta es az elso stable kozott:
http://googlechromereleases.blogspot.com/2011/04/beta-channel-update_97…
http://googlechromereleases.blogspot.com/2011/04/chrome-stable-update.h…

szoval nekem kicsit santa ez a nem voltak/lehettek felkeszulve magyarazat.
megsem az ejszaka leple alatt toltak be azt a nehany javitast meg adta ki az uj verziot.

Tyrael

Aztaaa... ma reggel bemondták a rádióban. :)

hacksagon is a hexaéder