Tweets by @buherablog
profile for buherator at IT Security Stack Exchange, Q&A for IT security professionals

A BitBetyár Blog

Túljártál a nagyokosok eszén? Küldd be a mutatványodat! (e-mail a buherator gmailkomra jöhet)

Full-Disclosure / Névjegy / Coming out


Promó

H.A.C.K.

Címkék

0day (110) adobe (87) adobe reader (21) anonymous (26) apple (60) az olvasó ír (49) blackhat (20) botnet (22) bug (200) buherablog (44) buhera sörözés (39) bukta (49) deface (38) dns (22) dos (29) esemény (82) facebook (26) firefox (64) flash (33) gondolat (31) google (59) google chrome (36) hacktivity (37) hírek (117) incidens (224) internet explorer (88) iphone (35) java (50) jog (22) kína (21) kriptográfia (68) kultúra (21) linux (24) malware (43) microsoft (142) móka (48) mozilla (23) office (26) oracle (40) os x (43) patch (197) php (20) politika (31) privacy (58) programozás (22) safari (34) sql injection (62) windows (85) xss (77) Címkefelhő

Licensz

Creative Commons Licenc

Google Chrome: helyesbítés?

2008.09.04. 17:52 | buherator | 6 komment

 Miután a Google helyesbítette a Chrome EULA-ját, most rajtam a sor, hogy felülbíráljam az új böngészőről szóló első posztomat:

Egy igen terjedelmes, ugyanakkor meglepően tartalmas vita alakult ki egy webjúzer nevet viselő olvasó kommentje nyomán, melyben arról volt szó, hogy a Chrome folyamatszétválasztási mechanizmusai - a nálam is megjelent állítással ellentétben - nem védenek meg a rosszindulatú kódfuttatástól illetve (mint ahogy a belinkelt exploit is mutatja) DoS támadásoktól.  Több helyen olvasható volt ugyanis olyan állítás, mi szerint a Chrome virtuális környezetben futtatja a megnyitott webalkalmazásokat, így azoknak esélyük sincs hozzáférni a fizikai memóriához.

Webjúzer ezzel szemben azt állítja, hogy megnézte a Chrome forráskódját, és ilyen jellegű szeparációval nem találkozott. Én hajlok arra, hogy a Google marketingjével szemben inkább neki higyjek, személyesen erről az állításról eddig nem volt alkalmam meggyőződni (ezt a posztot is sebtében dobálom össze éppen). 

A lényeg azonban az, hogy végül olyan vita alakult ki, melyből a néha elszabaduló indulatok ellenére sokan, sokat tanulhatnak, már ha van ereje az embernek végignyálazni 50+ hozzászólást

Címkék: privacy olvasó ír google chrome eula

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

synapse_a_paraszt 2008.09.05. 10:58:41

"ugyanakkor __meglepően__ tartalmas vita alakult ki"

lol :D

synapse

ff 2008.09.05. 14:06:41

Buhera, kezdesz már Te is bulvárosodni :) Szóval az hogy megvéd a rosszindulatú kódfuttatástól nyilván soha nem volt igaz, ahogyan a "fizikai memóriához hozzáférés" megakadályozása is kicsit furcsa ebben a formában. Én nem olvastam sehol ilyenre utalást, csak azt, hogy az oldalak szeparálva vannak egymástól, ez igaz is.
A sandboxozás (ami jelen esetben minden oldal külön processzben futtatását jelenti) azt akadályozza meg, hogy a külön tabon levő oldalak egymáshoz nyúljanak valami hiba által, illetve egy adott oldalban levő probléma (pl bof) ne rohassza le az egész böngészőt mint a firefox esetében. Az, hogy melyik hírportál mit képzel a marketing szöveg mögé pontos technikai információk hiányában, az más kérdés. A virtuális gépben futtatás egyébként szerintem a javascriptre vonatkozott, ami nem security hanem teljesítmény szempontból érdekes inkább, de ugye az is csak félig jit.

Hogy miért rántja magával az evil:% az egész böngészőt? Hát nyilván azért mert nem az oldal számára nyitott processben keletkezik a probléma, hanem a szülőben.

Nyiss egy process explorert, inditsd egy chrome-ot. Nézd meg mennyi processed van. Nyiss néhány üres tabot (nem változik), töltsd bele oldalakat (változik). Nézz velük másik oldalakat (változik a pidjük).
Tehát ha egy betöltött oldalban történik valami, akkor abbol nem fog (egyszerűen) kijönni a csibészség, ellenben minden művelet ami nem az adott processen belül történt, hanem a szülőhöz továbbítódik, az veszélyezteti az egész böngészőt, ez elég nyilvánvaló.

Tehát a szeparáció az megvan, a html motor, valamint a pluginek (flash stb) hibáinak esetében nem fogja összehányni magát az egész böngésző, csak az adott tab. Azonban persze az igazsághoz hozzátartozik, hogy ez security szempontból nem sokat ér önmagában. Tetszőleges kód futtatás esetén kit érdekel a többi tab vagy a szülő? :) Ha olyan funkcióban fogsz bugot ami szülőben kerül kezelésre, akkor is teljesen mindegy (lásd evil:%). Ráadásul mostanában a html motor hibáinak kihasználása helyett inkább a trükkös url-ek jellemzőek (firefoxban jar, chrome stb.), ezeket pedig a jelek szerint benyeli a chrome csúnyán, hiszen ott még köze nincs a kérésnek a "sandboxhoz"

Szerintem az zavarja meg az embereket, hogy felül vannak a tabok, ezáltal azt hihetnénk, hogy onnantól lefele minden a külön-külön process tulajdona, pedig a jelek szerint mégsem így van teljesen. Nyilván lehetne ezt jobban is csinálni, de gugliéktól ennyire futotta :> Ez is több mint a semmi, de nyilván lehetne még csökkenteni, hogy több dolog legyen szeparálva .

buherator · http://buhera.blog.hu 2008.09.05. 14:29:55

@ff
Hát igen, ezt teszi az időhiány, lesz még jobb...

Pont az általad leírtakat lehet megtalálni a belinkelt kommenteknél. A process szeparáció nem volt kérdés, hiszen ahogy te is írtad, erről meg lehet győződni egy egyszerű folyamatkezelőben. A "virtual machine" viszont egyértelműen security kontextusban szerepelt, és ezért következtettem az indirekt memória elérésre.

A sandboxinggal kapcsolatban a legnagyobb probléma egyébként a teljesítmény lehet, érdekes lesz látni, ha valaki végre előrukkol egy használható megoldással.

ff 2008.09.05. 15:11:25

@buherator

Én a rendes sandbox megvalósításának lehetőségében eleve nem hiszek egy böngésző esetében. Igazából már most is van jscript sandbox. Cookie domain korlátozások is, az is tekinthető sandboxnak. Viszont mi történik mondjuk iframe használatakor egy teljeskörű sandbox esetében? Ezeket vagy szimplán nem engeded, vagy engedményeket adsz a sandboxnak. Innentől ugye semmi értelme, hiszen pont ezek a kritikus pontok amikre figyelni kellene. Az egyéb esetekben pedig mint pl. tetszőleges kódfuttatás nem fog sokat érni, hiszen a másik tab tartalmának egyszerű kinyerése helyett már már kicsit nagyobb falatra vadászol.

synapse_a_paraszt 2008.09.05. 17:11:17

"Tetszőleges kód futtatás esetén kit érdekel a többi tab vagy a szülő? :)"

Hat a craxort, hogyha a gyerekprocess eldobja a privilegiumait ;)

synapse

sghctoma 2008.09.05. 17:57:07

itt egy pdf a témában: crypto.stanford.edu/websec/chromium/chromium-security-architecture.pdf

sajnos nincs sok időm mostanában, még nem tuddtam elolvasni.. talán egy pár kérdésre választ ad..
süti beállítások módosítása