Liczne słabe punkty w przeglądarce Google Chrome

W upublicznionej wczoraj przez Google'a wersji beta nowej przeglądarki Chrome stwierdzono obecność wielu słabych punktów stanowiących groźną lukę bezpieczeństwa. Stąd też producent zaleca ostrożne testowanie programu, mimo że na jego systemach firmowych nowa przeglądarka działa ponoć bez zarzutu.

Ekspert ds. bezpieczeństwa informatycznego Aviv Raff opublikował demonstracyjny exploit, który pokazuje skalę problemu. W przypadku odwiedzenia przygotowanej przez niego witryny na komputer użytkownika zostaje ściągnięte archiwum Javy (.jar) i zapisane w folderze przeznaczonym dla pobranych plików - wszystko to dzieje się oczywiście bez wiedzy internauty. Kliknięcie dość zgrabnie nazwanego przycisku pobierania w przeglądarce Chrome spowoduje uruchomienie apletu Java. W tym przypadku na ekranie pojawi się tylko napisany w Javie notatnik - rzeczywisty napastnik mógłby jednak doprowadzić do kompromitacji systemu. Do przeprowadzania skutecznego ataku konieczna jest wprawdzie współpraca użytkownika, ale pamiętajmy, że niektórzy klikają przycisk pobierania odruchowo.

Opisany exploit wykorzystuje prawdopodobnie znaną z Safari, a konkretnie z silnika WebKit tzw. bombę dywanową w połączeniu z pewnym błędem w obsłudze Javy. W przypadku mechanizmu określanego mianem Safari Carpet Bomb przeglądarka Safari umieszczała pobierane pliki na Pulpicie, nie pytając użytkownika o zgodę. Zagrożenie stawało się faktem, gdy ten korzystał z Internet Explorera, który w odróżnieniu od innych aplikacji wyszukuje biblioteki DLL także na Pulpicie. Apple rozbroił już bombę dywanową w wersjach silnika WebKit używanych przez Safari, począwszy od wydania 3.1.2. Niestety, Chrome wciąż korzysta z podatnej na ataki wersji 525.13, na której bazowało Safari 3.1. Miejmy nadzieję, że w finalnej edycji browsera Google zastosuje najnowszą wersję WebKita.

Opublikowano też inny demonstracyjny exploit, który stawia pod znakiem zapytania zachwalaną przez Google'a stabilność i integralność przeglądarki Chrome. Doprowadza on bowiem do całkowitego zawieszenia pracy programu. Koncern Google twierdził, że poszczególne witryny czy aplikacje są obsługiwane w oddzielnych kartach, podobnie jak procesy w swego rodzaju sandboksach. Zgodnie z tymi zapewnieniami ewentualne zakłócenia występujące w danej karcie nie miały wpływać na strony wyświetlane w pozostałych kartach czy też na aktywne aplikacje sieciowe.