Jak agencja PR ujawniła przed czasem błąd odkryty trzeci raz z rzędu
Od wczorajszego wieczora administratorzy maszyn linuksowych łatają błąd w bibliotece glibc, tzw. GHOST. Mało kto jednak wie, że błąd ten nie jest nowym odkryciem i został właśnie z wielkim szumem zidentyfikowany po raz trzeci.
Jeśli jeszcze nie czytaliście o GHOST, to na końcu artykułu znajdziecie dobre opisy techniczne. Jeśli już zaktualizowaliście serwery, to poczytajcie, jak ten sam błąd można odkryć trzy razy pod rząd i dopiero za trzecim razem pochwalić się całemu światu.
Błędy, grafika i agencje PR
Od przełomowego pod względem oprawy medialnej błędu Heartbleed (pierwszy z własnym logo, stroną www i ładną nazwą) co kilka tygodni ktoś próbuje powtórzyć sukces pierwowzoru. Shellshock, POODLE czy Misfortune Cookie przecierają drogę kolejnym niezbyt udanym projektom. Najnowszym ich przykładem jest GHOST, którego logo wygląda jak rysowane na kolanie, a do tego wszystko wskazuje na to, ze publikacja informacji o błędzie nastąpiła na skutek pomyłki agencji PR.
Logo błędu…
Niejaka Veronique Loquet z agencji PR AL’X Communication opublikowała informację o błędzie o 15:28 na jednej z list dyskusyjnych. Pół godziny później RedHat zdjął embargo z informacji i wieść rozlała się po całej sieci. Trudno powiedzieć, co w tej sytuacji jest bardziej niepokojące – to, że agencja PR przez pomyłkę rozesłała komunikat o kilka godzin za wcześnie, czy to, że agencja PR miała wiedzę o odkrytym błędzie zanim dowiedzieli się o nim branżowi specjaliści. Wygląda na to, że zamiast hakować komputery najlepszych ekspertów, NSA będzie mogła po prostu kontrolować komunikację agencji PR, by położyć rękę na informacjach o błędach typu 0day. Ciekawe czasy w których żyjemy najlepiej podsumował lcamtuf – polecamy.
Sensacyjne odkrycie – po raz trzeci
Najciekawszy w całej sprawie jest jednak dla nas fakt, że błąd „odkryty” przez firmę Qualys (jak sama twierdzi – w trakcie prowadzonego audytu) był już wcześniej odkryty co najmniej dwukrotnie, a co więcej był już załatany w momencie jego odkrycia.
Błąd w bibliotece glibc został poprawiony już 21 marca 2013 roku (pomiędzy wersją 2.17 a 2.18). Nie znamy szczegółów historii jego odkrycia – wiemy jedynie, że nie została wówczas prawidłowo oceniona jego waga i błąd nie został określony jako dotyczący bezpieczeństwa. Skutkiem tego wiele dystrybucji Linuksa nie zaktualizowało swojego kodu.
Z kolei w sierpniu 2014 na błąd natrafili pracownicy Google pracujący przy Chromium / ChromeOS. Niestety z ich dyskusji nie wynika, czy zdawali sobie sprawę z tego, że błąd był już wcześniej znany ani czy zadali sobie trud sprawdzenia, gdzie jeszcze występuje.
Trzeciemu odkrywcy, Qualys, należy się uznanie przede wszystkim za prawidłową ocenę wagi błędu oraz udowodnienie, że mimo znacznych ograniczeń może zostać on wykorzystany w praktycznym ataku na usługi dostępne publicznie. Gdyby nie ostatnie odkrycie być może historia tego błędu mogła trwać jeszcze kilka lat – a nie jest wykluczone że ktoś, kto pilnie śledził wcześniejsze odkrycia, mógł być bardziej domyślny od ich autorów i błąd mógł być wykorzystywany do niecnych celów. Wygląda zatem na to, że warto czytac cudze raporty i nie wierzyć w każde ich słowo.
Przydatne linki:
- lista podatnych dystrybucji i dostępnych łat
- pełny opis techniczny błędu
- po polsku skrót od Sekuraka
- analiza Rapid7
- [PDF] bardzo techniczny materiał o wykorzystywaniu błędów w glibc
Podobne wpisy
- Poznaliśmy hasło do bazy Albicla.com po raz trzeci plus wyciek kodu serwisu
- Jak ponownie mogliśmy poznać hasło do bazy serwisu Albicla.com
- Jak czytelnik zorientował się, że jego konto w mBanku nie jest już jego
- Takiej afery w mBanku jeszcze nie było – sprawdźcie, czy wasze konta są nadal wasze
- Setki tysięcy faktur były dostępne dla każdego klienta Selgros24.pl
Faktycznie, to co napisał Lcamtuf jest genialne,ma facet ten talent literacki oprócz hackerskiego :D
„Wygląda zatem na to, że warto czytac cudze raporty i nie wierzyć w każde ich słowo”
To tak jak z kodem na githubie. Będą przypadki nieprawidłowego załatania luki, ale to będzie może 1% albo mniej.Perełki są i będą,ale nic bez wysiłku. Problem w tym,że przeczytać,być krytycznym i poeksperymentować – do tego trzeba człowieka mającego czas i znającego się. Na pewno bogate agencje rządowe i jakieś organizacje hackerskie się z tego czegoś nauczą o 0-day-ach,ale nie przesadzałbym z optymizmem jeśli chodzi o np. środowisko hackerów tak white hat jak i black hat…
Tak z ciekawości panie Adamie,ty chyba odwiedzasz TORowe serwisy częściej – jakie są mniej więcej koszty zakupu 0-dayów ?
Ależ 0dayami chyba nikt w Torze nie handluje. Ten proceder odbywa się w eleganckich pokojach biurowców w Singapurze czy innym dużym mieście. Chyba że mówimy o 0day na phpBB, to wtedy rosyjskie fora.
No nic.Dzięki.O skalę sum właśnie chodziło. W takim razie możliwe,że jednak teoretycznie bugi są coś więcej warte niż bug-bounty x 10^1 || 10^2.
Kwestia opłacalności.Jeśli by tak było to takie rozwiązanie może się będzie opłacało komuś,bo liczenie 500 usd czy nawet kilka tysięcy nagrody to nie jest dużo jeśli zajmować się tym systematycznie miesiącami. Co mówić – może i spoza branży informatycznej jestem,ale robiłem poniekąd analizę danych / „kontrolę jakości” (z informatyki nic specjalnego,tyle co zautomatyzowałem skryptami VBA co się dało) więc wiem co to znaczy tego rodzaju „grzebanie w śmietniku”. Satysfakcja jest jak się coś znajdzie,ale satysfakcją się człowiek nie naje i nie ubierze,a zanim się coś istotnego znajdzie trafi się na masę popierdułek,i można dorobić się bólu głowy, bo wielokrotne przebrnięcie przez równoważnik kiepsko pisanej encyklopedii Britannica nie jest przyjemne i wygodne,a nawet automatyzacja nie ratuje przed wszystkim.
Dokładnie tak jak pisze Adam. Na TORze handluje się dowodami osobistymi, kontami bankowymi, słupami, wszelkiego rodzaju bazami i malware’em. Nigdy nie widziałem tam 0day’a. A jedynie malware wykorzystujący 0day po tym jak stał się 1day’em.
„PS. Tavis also points out that „>_” is not a standard unix shell prompt. We believe that such design errors can be automatically prevented with commercially-available static logo analysis tools.”
:D
Ubuntu 14.04 nie podatne