Ukazały się informacje o nowych lukach Zero Day odkrytych w przeglądarkach Internet Explorer 8 oraz Mozilla Firefox 3.6. Odkrywca obu luk opublikował również odpowiednie exploity, pozwalające na zdalne zakłócenie pracy obu popularnych programów. Z punktu widzenia końcowego użytkownika, atak powoduje nieodwracalną utratę kontroli nad przeglądarką (ang. Denial of Service) oraz potencjalną utratę danych edytowanych w trybie online.
Asheesh kumar Mani Tripathi odkrył w Internet Explorerze 8 błąd obecny w kontrolce ActiveX history.go. Luka pozwala intruzowi na wykonanie dowolnego kodu, alokację pamięci oraz awaryjne zakończenie pracy samej przeglądarki. Przygotowany przez HCSL, przykładowy exploit Proof of Concept można pobrać pod tym adresem. Uwaga! Ta specjalnie spreparowana strona internetowa, po jej otwarciu w przeglądarce IE8, spowoduje nieustanne wywoływanie systemowego polecenia ipconfig oraz całkowitą utratę kontroli nad przeglądarką.
Asheesh odkrył również podobny błąd w Firefoksie 3.6, obecny w funkcji put window.printer(). Luka pozwala intruzowi na całkowite zakłócenie pracy przeglądarki. Przygotowany przez HCSL, przykładowy exploit Proof of Concept można pobrać pod tym adresem. Uwaga! Otwarcie tej strony internetowej w przeglądarce Firefox 3.6, spowoduje nieustanne wywoływanie funkcji drukowania oraz całkowitą utratę kontroli nad przeglądarką.
Podsumowując, do udanego wykonania obu ataków, wystarczające jest więc zwabienie użytkownika na specjalnie przygotowaną stronę internetową.
Przedstawione przykłady stanowią kolejny dowód na to, że niezależnie od rodzaju używanej przeglądarki internetowej, nigdy nie możemy liczyć na w pełni bezpieczną oraz stabilną pracę. Natomiast sam proces odkrywania nowych luk oraz ich łatania przez twórców oprogramowania przypomina nieustanny wyścig zbrojeń i nie daje żadnej nadziei na jego rychłe zakończenie.
Materiał pochodzi z serwisu HARD CORE SECURITY LAB.
Nie "Firefoks", tylko Firefox. Gdzie zniknął formularz do zgłaszania literówek?
I tak na marginesie – owe "przygotowane przez HCSL" przykładowe exploity, to przecież kopie exploitów opublikowanych na Full Disclosure.
Gotowe w sensie, gotowe pliki html przygotowane do pobrania i przetestowania w wygodny sposób, nigdzie nie przypisuję sobie autorstwa, linkuję do oryginału.
Sformułowanie "przygotowane przez HCSL" jest o tyle niefortunne, że sugeruje, że sam je przygotowałeś, czyli jesteś autorem. Ja tak to odebrałem, czytając newsa.
I teraz należy włączyć stopery i mierzyć czas, jakie zajmie wypuszczenie każdemu twórcy stosownych aktualizacji.
trudno to nazwać luką. Przeglądarka poprawnie wykonuje kod, a że jest napisany w ten sposób aby wkurzyć usera, no cóż.
okno jest modalne
Działa również na chromium.
Na konqueror tez 😛
Dlatego warto czekać, aż każda strona internetowa w Firefox4 będzie oddzielnym procesem.
Ten "exploit" z drukarką to kpiny jakieś ;). To tak jak by exploitem nazwać taki kod:
<code>for (;;) alert('coś');</code>.
Zrób jakiś PoC, to zobaczymy, czy Twój exploit całkowicie "zabije" przeglądarkę lub pozwoli na uruchomienie dowolnego kodu…
Niestety Twój "exploit" nie powoduje całkowitej utraty kontroli nad żadną z popularnych przeglądarek w najnowszej wersji, tak jak to ma miejsce w przypadku dwóch opisanych powyżej przypadków. Czekam na następne propozycje.
IE6 nie odda kontroli użytkownikowi. Będzie nawet problem z zamknięciem okna.
Twoj rowniez (w wersji na Firefox) nie powoduje calkowitej utraty kontroli (przynajmniej nie u mnie) – print i reczne zamkniecie zakladki. W moim wypadku byl to wydruk do pliku, przy normalnej drukarce mysle, ze wystarczy po prostu miec ja wylaczona.
Właśnie miałem się podzielić moim odkryciem, ale byłeś szybszy. 🙂
Sęk w tym, że opisane przeze mnie przykłady nie pozwalają w żaden sposób na przerwanie pętli, a Twój for w Chrome oraz Operze już po 1 wyświetleniu okna powoduje pytanie o zaprzestanie wykonywania skryptu, w FF w ogóle to nie działa, a IE8 też się całkowicie nie wywala.
imho hiciu wyraźnie napisał ale objaśnię to jaśniej
sarkastyczne pozdro dla hcsl.pl
<code></code>
<html><body onload="for(;;)alert('cos');"></body></html>
A to w ogóle nie działa…
Działa – trzeba zamienić cudzysłowy i apostrofy na "normalne", w praktyce wkleić powyższe do notatnika i usunąć i jeszcze raz napisać cudzysłowy i apostrofy. Może WordPress automatycznie zmienia na inne znaczki unicode?
Po otwarciu pod firefox jako stronki html powoduje, iż nie można zamknąć karty, przerwać wykonywania skryptu, zamknąć przeglądarki ani zmienić aktywnej karty na inną, gdyż cały czas okno z alertem ma focus i jest modalne. Trzeba killować proces przeglądarki.
Nie powoduje to jednak utraty danych wpisanych w formularzach, więc hipotetyczna sytuacja, w której obawialibyśmy się utraty długo pisanego maila/komentarza/etc nie nastąpi – po ponownym uruchomieniu programu z przywracaniem sesji (i odznaczeniem przy uruchamianiu wczytywania felernego pliku) formularze są wypełnione tak, jak przed ubiciem. Może to jednak być zasługa jakiegoś rozszerzenia, np. SessionSaver – nie jestem pewien, nie testowałem na czystym profilu.
UWAGA! Zganazłem potencjalnie groźny błąd w programie Bash: napisanie :(){ :|:& };: powoduje w niesprzyjających warunkach nieodwracalną utratę kontroli nad procesem Bash!
Uśmieszek fail.
Jednak błąd w przeglądarce istnieje. Nie jest to błąd bezpieczeństwa, lecz przeglądarka nie powinna się wieszać na jakiejś stronie, bo prowadzi to np. do zamknięcia procesu. W przypadku Bash-a, to nie ma problemu – program zacznie wykonywać nieskończoną pętle, to go ubijasz. W przypadku przeglądarki, to już duży problem. Jednak ten problem się sam rozwiąże, gdy twórcy Firefoksa wprowadzą użycie wielu procesów(jeden na stronę), bo wtedy co najwyżej zawiesi się strona.
Jest to błąd bezpieczeństwa, błędy pozwalające na całkowite wywalenie czegoś zaliczamy właśnie do tej kategorii. W grę wchodzi również przecież potencjalna utrata danych edytowanych online w jednej lub kilku zakładkach. Jeśli przykładowo ktoś pisał bardzo, bardzo długiego maila bezpośrednio w przeglądarce, lub np. bardzo długi opis aukcji w formularzu "do wystawienia" na Allegro i po drodze odwiedzi taką stronkę, która wywali całą przeglądarkę, może się trochę zdenerwować.
@hcsl.pl: akurat w przypadku maila nie straci więcej niż 10 s. pisania. Podobnie jest chyba z Allegoro, ale nie dam sobie ręki uciąć.
Z Allegro pozostanie nawet historia przeglądanych aukcji.
W np. gmailu maile są automatycznie zapisywane na serwer co określony czas. Nie wiem czemu minusujecie, pisze całkiem z sensem (mimo, że w przypadku np. pisania komentarza na tej stronie mogę go utracić).. W żadnym wypadku nie jest to luka bezpieczeństwa. Luka bezpieczeństwa to np. możliwość przechwycenia haseł/plików na dysku czy wykonanie kodu (tak jak to jest w opisywanym powyżej przypadku odnoszącym się do IE8). Tutaj można mówić np. o błędzie stabilności(?).
Dostępność (możliwość skorzystania z danej usługi, czy programu w wymaganym miejscu i czasie) to jedna z podstawowych kategorii bezpieczeństwa.
http://pl.wikipedia.org/wiki/Dost%C4%99pno%C5%9B%…
😀 teraz poczekamy na łatki Mozilli i MS i zobaczymy kto ma bezpieczniejszą przeglądarkę 😀
PS dobrze rozumiem, że tekst o wykonaniu dowolnego kodu dotyczy tylko IE8 ?
Nie sprawdzałem ale czy w FX na Linuksie okno do drukowania jest oddzielnym procesem? Jeżeli tak to: ulimits -u też zablokuje atak na FX.
Jest oddzielnym. Dlatego o wiele bardziej wnerwia. No i trudniej karte z tym skryptem wyłączyć. Sprawdzałem.
Nie jest. To okienko firefoxa.
na komputerze z KDE 3.5 (Slack) powoduje niemal totalny zwis, mysz trochę się rusza, ale bardzo niemrawo. Nie badałem, czy da sie z tego wyjść, bo szkoda było czasu – nie dało się ani przejść na konsolę (klawiatura), ani podmontować z zewnątrz zasobów NFS, czy zalogować się po ssh. Ale np. we Fluxboksie czy XFCE nie robiło to nic.
nie wiem co ma do tego srodowisko graficzne, jedyna rzecza ktora ma wplyw na ta fork bombe ma ustawienie limitow na ilosc procesow : ulimit -u no i chyba to ze moze jakis shell nie kuma skladni czy cos
też nie wiem, ja tylko takie zjawisko zauważyłem. Jeszcze to z ciekawości sprawdzę, także na SUSE. Może to była kwestia różnych terminali użytych w tym eksperymencie? nieco nieprzyjemnym dla komputera, trzeba przyznać (w dodatku klawisz reset w nim nie działa, chyba źle podłączony); w sumie to całkiem efektowne (na swój sposób) doświadczenie: wysyłasz maszynie, np. przez ssh, te parę znaczków i jakby ją zamroziło coś. System jest "waniliowy", pewnie poważne maszyny mają jakieś zabezpieczenia, bo inaczej wesołym zabawom niebyłoby końca.
To faktycznie nie ma związku z win managerem, jak mi sna początku wydawało. Jakieś inne okoliczności powodują, że czasem działa, ale nie wiem jakie. Finis
NoScript daje radę 😉
taa… smutna historia.
gosc na twitterze chwalil sie nim: http://twitter.com/elegerov/status/8781259750 – probowalismy sie z nim skontaktowac, ale wyglada na to, ze pracuje on dla firmy ktora zbiera luki w celu sprzedazy ich "firmom chcacym sie ochronic", a tak naprawde komukolwiek.
widzialem na #security, ze pierwsze buildy z poprawka juz sie gotuja. Natomiast nie wiem czy #sec-team uzna to za na tyle powazny blad by wydawac update od razu czy poczekaja az kilka sie zbierze.
FF 3.5.7 i chroma w mincie też trzeba wymusić zakończenie.
A mi to to nie zabiło IE8 na wirtualnej maszynie. W zasadzie to IE nic nie zrobiło poza zadaniem mi 4 upierdliwych pytań z serii 'Czy włączyć formant ActiveX?' i nie wyświetleniu niczego.