#hacking krytyczny błąd w libc pozwala atakować prawie każdy program sieciowy (o ile robi on "getaddrinfo" - np jeżeli wysyła zapytania DNS). Poprawki już wyszły (np debian), wystarczy update i reboot.
Do skutecznego ataku wystarczy kontrolować DNS (lub, oczywiście, łącze internetu - w tym np złamać hasło WiFi, co jest trywialne dla większości użytkowników bo mają proste krótkie hasła lub słownikowe). Oczywiście różne metody (AFAIR w tym ochrona stack, np randomizacja ASLR) spowolni/utrudni atak zamieniając go w tylko wysypywanie się atakowane programu/serwera, zamiast przejęcie nad nim kontroli)
@FLAC: lol xD W windows więcej dziur tylko mniej się o tym mówi.
Natomiast, faktycznie, co ci niekompetentni programiści to ja nie wiem.
Może wyjściem była by statyczna analiza kodu w C/C++, oraz odchodzenie od ręcznego zarządzania pamięcią, na rzecz bezpiecznego subsetu C++, oraz co się da wyrzucać jeszcze wyżej np do języka skryptowego wbudowanego (jak LUA). Jak myślisz, @Siotson
@rfree: Pisząc w nowoczesnym C++ takie coś jest równie moƶliwe jak w ruście (wcale) :P ale glibc jest raczej w czystym C, który jest zdecydowanie bardziej prymitywny i wraƶliwy na tego typu problemy.
A co do błędów: nawet najlepsi je popełniają, dlatego warto postarać się wyrobić taki proces, który je znacząco zniweluje (np. w języku Rust byłoby to błędem kompilacji :) )
@rfree: @KrzaQ2: Zupełnie nie rozumiem tej "konieczności" pisania tego typu bibliotek w C. Jasne - musimy mieć często kontrolę nad wykonaniem programu na bardzo niskim poziomie chociażby po to, żeby nie narazić się na time attack. Jednak C++ jest w bardzo dużym stopniu kompatybilny z C a nikt mi nie wmówi, że buffor na odpowiedź DNS nie może być chociażby std::string.
@calka: niepotrzebnej zupełnie. Większość bibliotek wymaga przepisania kodu na nowo ale ludziom się nie chce. A jak któraś wymaga const char * to się jej to da. A poźniej będzie płacz, bo buffer overflow ;|
@pingwindyktator: problem jest trochę bardziej złożony. O ile można mówić o przepisaniu apek mając na myśli te nie do końca mainstreamowe, to jest to do zrobienia. Przepisanie na ten przykład libc, a przy okazji wprowadzenie jakiś bugów, miało by spore konsekwencje. Dlatego ISO C++ idzie drogą, już dawno ustaloną, że wsteczna kompatybilność jest kluczowa. Przy okazji wszyscy na to klną (na czele z Bjarne, Herbem Sutterem i innymi). :) Niemniej,
#linux #security #itsecurity ; nie wiem czy też nie #bsd czy tam inny mac.
CVE-2015-7547
https://googleonlinesecurity.blogspot.com/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html
https://news.ycombinator.com/item?id=11109967
Do skutecznego ataku wystarczy kontrolować DNS (lub, oczywiście, łącze internetu - w tym np złamać hasło WiFi, co jest trywialne dla większości użytkowników bo mają proste krótkie hasła lub słownikowe).
Oczywiście różne metody (AFAIR w tym ochrona stack, np randomizacja ASLR) spowolni/utrudni atak zamieniając go w tylko wysypywanie się atakowane programu/serwera, zamiast przejęcie nad nim kontroli)
@TX1683 @fervi @ZaufanaTrzeciaStrona @niebezpiecznik-pl
@flac @tyskieponadwszystkie bo #bitcoin ( ͡€ ͜ʖ ͡$)
#cpp #programowanie trochę, #siecikomputerowe
Natomiast, faktycznie, co ci niekompetentni programiści to ja nie wiem.
Może wyjściem była by statyczna analiza kodu w C/C++, oraz odchodzenie od ręcznego zarządzania pamięcią, na rzecz bezpiecznego subsetu C++, oraz co się da wyrzucać jeszcze wyżej np do języka skryptowego wbudowanego (jak LUA). Jak myślisz, @Siotson
A co do błędów: nawet najlepsi je popełniają, dlatego warto postarać się wyrobić taki proces, który je znacząco zniweluje (np. w języku Rust byłoby to błędem kompilacji :) )
C pozwala na zbyt wiele, aby statyczna analiza
time attack. Jednak C++ jest w bardzo dużym stopniu kompatybilny z C a nikt mi nie wmówi, że buffor na odpowiedź DNS nie może być chociażbystd::string.const char *to się jej to da. A poźniej będzie płacz, bo buffer overflow ;|Niemniej,
@pingwindyktator: ( ͡°( ͡° ͜ʖ( ͡° ͜ʖ