Biztonsági hibát talált a Microsoft a Google Chrome Frame-ben

 ( trey | 2009. november 20., péntek - 13:30 )

A Google szeptember végén jelentette be Google Chrome Frame névre hallgató IE plug-in-jét, amellyel megérkezett a Google Chrome renderer-je és Javascript engine-je az IE-be. A Microsoft szóvivője akkor azt nyilatkozta, hogy cége nem ajánlja a plug-in telepítését az IE felhasználóknak, mert azzal csökken az Internet Explorer biztonsága.

A Google véleménye az volt, hogy nem hogy csökken, hanem javul a Microsoft böngészőjének biztonsága a plug-in-től. A konkurens Mozilla is megszólalt az ügyben, és szintén nem tartotta jó ötletnek a Google elképzelését.

Most a Google Chrome Frame plug-in frissült, és a változások listája közt az olvasható, hogy Billy Rios és Microsoft Vulnerability Research (MSVR) egy "high" súlyosságú "cross-origin bypass" biztonsági hibát talált és jelzett a Google termékében. A hiba javításra került, a frissítés hamarosan megérkezik a Chrome Frame felhasználókhoz. Mark Larson, a Google Chrome Team részéről megjegyezte, hogy a "high" súlyosság ellenére a hiba nem teszi lehetővé a felhasználó gépének maradandó malware-rel történő fertőzését.

A részletek itt.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

lol.

Ezek milyen jól el fognak játszadozni egymással a következő években... :)
Popcorn bekészít.

Legalább dolgoznak. Gondolom nem kis célprémium volt feldobva a Microsoft-nál ;)

--
trey @ gépház

Meghiszem azt!
De nem csak a konkurencia pluginjét kéne vizsgálgatniuk, hanem a saját böngészőjüket is... Sztem az is rájuk férne...

+1 ha az IE-t vizsgálgatnák ilyen erővel, nem lenne rossz.
---
;-(

na majd ha ők is tortázgatnak... ;)

Ebből is látszik, hogy milyen jó ez a Google Chrome Frame, hisz a Microsoftnak két hónapig kellett keresnie benne egy hibát! :)

:D aki keres, az talál

Vagy a Google-nak tartott 2 hónapig a javítása. Vagy 2 hét alatt megtalálta a Microsoft, a Google 2 hét alatt kijavította, majd mindkét csapat elment sörözni 2 hétre, és további 2 hét volt a kijózanodás. Vagy nem.

Mondjuk az is egy jó biztonsági mutató, hogy a hibákat ki mennyi idő alatt javítja. :))

--
Debian - The "What?!" starts not!
http://nyizsa.uni.cc

Persze ha a másikon kell fogást keresni... Remélem lesz visszhangja, és a gugli is megoszt pár hibát

es vajon hany ms hibat kuszobolt ki a hasznalo egyebkent?

De most nem azért, ki használ IE-t?

A titkárnő, akinek a "zinternet" egyet jelent a kék e betűvel.

Vallalati kornyezetben sokan.

Ahol nem addonokra van szukseg, hanem pl. kozponti menedzselhetosegre.

----------------------
while (!sleep) sheep++;

És ha esetleg addonokra volna szükség, még azok is vannak bőven, magyarok is: http://www.ieaddons.com/hu/popular/?sort=views&lang=hu

Üdv,
mrceeka

Ezek csak IE8-tól működnek, és vállalati környezetben úgyse telepíthetsz semmit.
---
;-(

User profilba miert ne?
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Mert kockazati tenyezo.

---
pontscho / fresh!mindworkz

Kifejtened?
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Nagyvallalati kornyezetben (mondjuk kisebb infrastruktura eseten sem) a paraszt ne installaljon _semmit_ csak ugy engedely nelkul, mivel minden uj komponens uj kockazati tenyezo a rendszer szempontjabol mert noveli annak komplexitasat.

A gyakorlatban nem ugy mukodik egy gep park karbantartasa mint egy putter debian szervere, h napkozben kiadok egy apt-get update-t aztan lesz valami. Minden app egy hosszadalmas kompatibilitasi, stabilitasi es megbizhatosagi teszten kell, h atessen mielott engedelyezik. Viszont mivel az IT mindig alul van meretezve ilyen marhasagokra nem marad ido.

---
pontscho / fresh!mindworkz

+1. Hozzá kell szokni, hogy nagyvállalati környezetben KELL a központi management lehetősége, amit a FF gyakorlatilag nulla szinten képes abszolválni. Volt rá kezdeményezés, de elhalt -- sajnos.

Mindig megkérdem itt, de soha nem kapok rá értelmes választ.Vagy én nem értek a böngészéshez, vagy egyes vállalatok a tűzfalakhoz.
A nagy központi manageles kozben, mit szokas atallitani olyan gyakran ?


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

+1, mit akarhat valaki központilag beállítani a userek böngészőjében?

--
Debian - The "What?!" starts not!
http://nyizsa.uni.cc

Pl. letiltani/engedelyezni az ActiveX-et, kulonfele bongeszobeallitasok kozponti menedzseleset AD-n keresztul, stb. Kb. ezer beallitasi modja van az IE-nek is, kezdve azzal, h AD-bol tiltani is lehet a paraszt hozzafereset akarcsak a bongeszohoz. Fantazia, hasznaljatok. ;)

---
pontscho / fresh!mindworkz

Kezdőlap, cache-paraméterek, proxy-beállítások, az "Eszközök" - "Internet-beállítások" "Speciális" fülön található rengeteg paraméter (és az ott nem található registry-ben lévő egyéb cumók). Meg ami a legfontosabb, a beállítások felhasználó általi módosításának az engedélyezése/tiltása, akár egyesével.

Nem az "olyan gyakran"-on van a hangsúly, hanem az egységesen kikényszeríthető policy alkalmazásán. FF-ban hogy tiltod le pl. azt, hogy a felhasználó matassa a proxy-beállításokat?

Le lehet tiltani, nalunk pl. le van -- van valami preference konstans az egyik konfigfajlban. (Persze az is kell hozza, hogy a felhasznalo a sajat gepen ne tudja atirni azt a bizonyos konfigfajlt, ami fejlesztoknel maceras, hiszen csomo fejlesztes csak adminisztrator felhasznaloval vegezheto el rendesen.)

----------------------
while (!sleep) sheep++;

"Le lehet tiltani, nalunk pl. le van -- van valami preference konstans az egyik konfigfajlban."

Azaz ezt minden gepen egyesevel kell beallitani, attol fuggoen, hogy mi a szerepkore a felhasznalonak? Na pont erre valo a Group Policy, amikor belepsz a domainbe, akkor szepen beallitodik minden. Ha mondjuk mas csoportba tartozol holnaptol (teszem azt, kineveznek kisfonoknek), beallitod az AD-ben a masik csoporttagsagot, es a kovetkezo loginkor mar az uj beallitasok ervenyesek, a sysadminnak nem kell meg a gepedhez sem nyulnia, az AD-ben beallitja, es kesz.

En ertem, ne nekem mondd :)

----------------------
while (!sleep) sheep++;

"csomo fejlesztes csak adminisztrator felhasznaloval vegezheto el rendesen"

Akkor ott valami marhára nem kerek.

Hat, vonatkoztass el egy kicsit a szamlazoprogramtol :)

----------------------
while (!sleep) sheep++;

Annál picit komolyabb dolgokkal is foglalkoztam...

Tenyleg a rendszergazdaval lehet ott gond, ahol nem lehet megoldani a fejlesztok !admin gepet. A dolog _megoldhato_ max a fejleszto nem fog ugralni oromeben, de vajon melyik cel a fontosabb?
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

"FF-ban hogy tiltod le pl. azt, hogy a felhasználó matassa a proxy-beállításokat?"

És ha matatja? Letiltod tűzfalból, hogy a proxy megkerülésével netezzen. Ami kicsit biztonságosabb, mert ha letölt egy portable firefox-ot, és azt használja, akkor se tudja megkerülni a proxyt. (Persze biztos lehet kioskot adni a felhasználóknak, és letiltani, hogy saját programot futtassanak, de tűzfallal egyszerűbb és biztonságosabb megcsinálni, hogy ne lehessen megkerülni, és a felhasználókat se korlátozza fölöslegesen.)

Egy kkv-s környezetben valóban ilyen egyszerű a dolog, nagyobbacska cégnél azért lehet bonyolultabb is, pl. nem mindenkire vonatkozik ugyanaz a proxy-beállítás (vannak "egyenlőbbek"), akkor mit csinálsz? Vagy van, akinek attól függetlenül, hogy hol dugja be a gépét, proxy nélkül/az általánostól eltérő proxybeállítással kell kilátnia a világba, viszont admin jogra nincs szüksége?

Proxy autentikáció, felhasználótól függő beállításokkal?

Hopsz, megeloztel joval..


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Az is userfüggő, hogy melyik proxy-t kell megszólítania a sok közül. Hmmm? Mondom, nek kkv-s környezet, ahol van néhány(tucat) user, egy proxy, aztán jó'cakát.

Chrome úgy tűnik, a rendszerbeállításokból szedi a proxybeállításokat. Talán Firefox-hoz is van ilyen addon.

A proxy-beállítás csak egy az 123...789 paraméter közül...

Akkor mi olyan fontos? mrceeka linkelte a beállítható dolgok listáját - nekem úgy tűnik, ezek vagy fölöslegesek, ha nem kioskot csinálunk, vagy kiválthatók, ha proxyból/tűzfalból korlátozzuk a dolgokat.

Ha pedig kioskot csinálunk (tehát olyan rendszert, ahol a felhasználó csak néhány meghatározott dolgot csinálhat, ami a munkához kell), akkor a webhasználatba is csak whitelist-tel meghatározott, megbízható oldalak férnek bele (hiszen ma már kb. bármire lehet weben is használni a gépet, ha néhány kivételével bármilyen oldalt használhat); ilyenkor nincs nagy jelentősége a biztonságnak, így a google frame-nek se.

Neked úgy tűnik -- másnak (akik foglalkoztak már jelentős méretű céges hálózatban desktop-ok támogatásával, biztonsági szabályok kialakításával és betartatásával) azoknak meg nem tűnik egyáltalán feleslegesnek -- ahogy szerepel is a topicban, a biztonsági zónák beállításai, egyes szerverek zónákba sorolásának kikényszerítése és hasonló dolgok igen fontosak tudnak lenni.

Opsz, zónákba sorolás... A group policy-s menedzsment mellett ezt sem lenne hülyeség implementálni...

Az mond neked valamit, hogy authentikacio a proxy -n ? Esetleg az hogy kerberos ?


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Naná... Van 2-9 darab proxyrendszer párhuzamosan, 2-9 féle tűzfallal. AD az van, de az userek 2-9 domainben leledzenek, néha terminálszervert kénytelenek használni, néha más PC elé kell lehuppanniuk (mert a sajátjuknak valami zizije van)...

2-9 Domain(Realm) nem bizik egymasban ? Kerberosos Proxy-t elvileg mindket bongeszo tamogatja.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Megvonod az iras jogat a props.js -re, de en ilyet nem teszek szegenyekkel.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

3-5000 ember gépén, egyenként... Aztán ha változtatni kell, akkor ugyanennyi gépen nekilátsz helyrematatni...

Login script, kb. a Policy is akkor lep eletbe.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Eeee... ooo.... haaat... mondjuk azt, hogy ha a kulonbseget zongorazni lehetne, hangverseny kerekedne belole.
--

()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Szerintem ez itt nem böngészés kontra tűzfal kérdés. Jópár olyan dolgot akarhatsz kontrollálni, amit tűzfallal nem tudsz.
Hogy áttekintő képed lehessen arról, mi minden szabályozható csoportházirendből, legegyszerűbb, ha átfutod a következő táblázatot:
Group Policy Settings Reference for Windows Internet Explorer 8

Üdv,
mrceeka

Mar nem egyszer atfutottam.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Ezek közül mit kell rákényszeríteni a felhasználókra, ha nem kioskot csinálsz?

Rákényszeríteni azt kell, amit a céged belső szabályzatai vagy azok végrehajtási utasításai előírnak.
Ha nem vagy ennyire szabályzott környezetben, akkor meg amit a józan eszed/főnököd diktál...

De hogy ne értsem félre szándékosan a kérdésed, néhány tipikusan group policyból szabályzott böngészőbeállítás:
-proxy beállítások, proxy autoconfiguration
-temporary internet files beállítások
-favorites céges belső tartalommal
-home page beállítás (óvatosan)
-search bar belső keresőre irányítása
-biztonsági beállítások zónáinak beállítása (egyes helyek kényszerítése bizonyos zónába, pl. Trusted Sites-ba)
-egyes zónák biztonsági szintjeinek kényszerítése (tipikusan az Internet zóna szigorúra véve, a munkához kellő,
de azzal ütköző oldalak Trusted Sites-ba véve). ActiveX, Scripting, File- és fontletöltés, clipboard hozzáférés, pop-up blocker stb.
-addonok
-ha a cég igényli, böngészőtestreszabás a belső marketing kívánalmainak megfelelően

Üdv,
mrceeka

Értem. Ha jól gondolom, ezek olyan dolgok, amiket nem biztonsági probléma a cég számára, ha valaki megkerül, hanem olyan alapértelmezések, amik hasznosak/szükségesek a felhasználóknak, és kényelmesebb központilag állítgatni őket, mint mindenkinek leírni, hogy hogy kell beállítani. Erre viszont valóban hasznos.

Vedd hozzá azt is, hogy ezek (pl. zónába sorolás, zónák biztonsági beállításai) idővel változhatnak, amit egyszerűbb policyból érvényesíteni, mint 123456 usernek elmagyarázni, hogy mit és hogyan, illetve a támogatónak is egyszerűbb a dolga: hibabejelentés esetén pontosan lehet tudni a felhasználónál lévő böngésző beállításait.

Szerintem nem jól gondolod, mert ezeknek csak egy része ilyen.
A biztonsági jellegű beállítások fontos részt tesznek ki az Internet Explorer beállításokból, ahogy azt zeller is kiemelte.
Nagyon fontos, hogy egy intraneten üzemeltetett (helyenként: üzemeltetni kényszerült!) alkalmazás böngészésekor egészen más biztonsági beállításaid lehessenek, mint az Internet böngészésekor. Mondjuk ennél az ismert, belső alkalmazásnál engedélyezed az aláíratlan ActiveX automatikus letöltését és futtatását, míg ugyanez az Internet zónán életveszély.

Üdv,
mrceeka

Ha a felhasználó valamilyen beállítás megkerülésével, saját szakállára telepít egy káros ActiveX plugint, azzal csak a saját felhasználói fiókját barmolhatja szét, meg azt, amihez neki joga van. Amihez neki joga van, azt viszont mindenképp szétbarmolhatja - amiért persze ő lesz a felelős. (Az más kérdés, hogy AFAIK a konkrét esetben más böngészővel ez eleve nem lesz probléma, mert nem támogatja az ActiveX-et, így ha az kell, nyilván a belső, megbízható szolgáltatáshoz IE-t használnának.)

Anélkül, hogy mélyre merülnénk a részletekbe:
-biztonsági beállításokról és messze nem csak ActiveX-ről van szó, kár is volt példaként épp ezt felhoznom, félrevezettelek vele. Pl. lásd másik hozzászólásom a 0day workaroundjáról.
-"csak a saját felhasználói fiókját barmolhatja szét": ez nem így van, lásd http://en.wikipedia.org/wiki/Privilege_escalation

Üdv,
mrceeka

Ha privilege escalation bug van, azt meg maga a felhasználó is kihasználhatja, ha szét akarja barmolni az egész rendszert. Azaz saját érdeke, hogy ne futtasson nem megbízható dolgot, hogy ha ilyen hiba van, akkor ne vonják felelősségre azért, mert az általa futtatott program a privilege escalation bugot kihasználva elbarmolta az egész rendszert. Úgyhogy itt megint arról van szó, hogy ActiveX vagy egyéb hasonló dolog kihasználásával csak olyan bugot használhat ki, amit enélkül is kihasználhatna - úgyhogy itt is saját érdeke, hogy ne telepítsen megbízhatatlan dolgokat, amiben szintén valóban segít, hogy egyszerű módon/alapértelmezés szerint ne telepíthessen.

Ne haragudj a direkt kérdésért, de nagyságrendileg mekkora volt a legnagyobb cég, ahol supporttal/üzemeltetéssel foglalkoztál?

Nem foglalkoztam vele, de ettől még érdekelhet, hogy valami miért úgy működik, ahogy szerintetek működik, ha nekem nem így tűnik.

Mindjárt gondoltam :-) A központi beállításoknak az egységes kialakítása miatt a támogatás, a support is egyszerűbb, a változáskezelés is csak néhány kattintás -- úgy az OS-re, mint a böngészőre vagy az egyéb alkalmazásokra vonatkozólag. Néhány gép esetén még csak végig lehet kattingatni a dolgokat, illetve a registry-fájlt fel lehet hajítani a gépekre -- egyszer. Aztán ha kderül, hogy valamit módosítani kell, akkor goto 10, új kattintgatás, új reg fájl, annak a disztributálása, feldobálása a gépekre... Horror. A központi menedzsment tehát elsődlegesen a támogatók életét könnyíti meg.
Az, hogy egy böngészőnek, vagy bármelyik más alkalmazásnak milyen paramétereit menedzselik/állítják be központilag, az döntés kérdése, biztonsági szempontból viszont tény, hogy ezzel ki lehet kényszeríteni a céges szabályozás betartását a biztonsági beállítások terén is.

Mivel az egyes alkalmazások beállításai felhasználói csoportonként, vagy akár userenként is eltérőek lehetnek, így mindenképp valamilyen, az userhez kötött megoldásra van szükség. A logon script is lehet(ne) megoldás, és van, amire csak így van mód (mert az alkalmazás nem használja a registry-t), azonban ez a scriptelős móka a gp-hez képest igencsak fapad, ráadásul egy idő után a karbantarthatóság sem az igazi, hogy finoman fogalmazzak...

"Ha a felhasználó valamilyen beállítás megkerülésével, saját szakállára telepít egy káros ActiveX plugint, azzal csak a saját felhasználói fiókját barmolhatja szét"

Marmint azon tul, hogy ezen keresztul felzuzzak a komplett ceges halot?

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

Akkor ott valami eleve nem volt rendben, mert az azt jelenti, hogy maga az adott felhasználó feltörhetné az egész cég hálózatát. Pedig most épp arról volt szó, hogy korlátozzuk-e a felhasználót - aminek nem nagyon látom értelmét, ha olyan szinten van a biztonság, hogy egy felhasználó az egészet felnyomhatja.

Megfelelően (ki)képzett felhasználó képes rá, ettől még kell az elővigyázatosság.
http://en.wikipedia.org/wiki/Privilege_escalation

"az azt jelenti, hogy maga az adott felhasználó feltörhetné az egész cég hálózatát"

Maga a felhasznalo mindig sokkal egyszerubben feltorheti az egesz ceg halozatat, mint aki csak a tuzfal kulso labat tudja pingelni.

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

És még egy aktuális: Microsoft Internet Explorer CSS Handling Code Execution Vulnerability (0day)
Workaround: Active Scripting letiltása az Internet és Local intranet biztonsági zónákban

Üdv,
mrceeka