[rfree]

#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.

#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

[FLAC]

@rfree: ja siedzę na windowsie więc jestem bezpieczny, a linuks jak widać co chwila nowe dziury

[rfree]

@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

[FLAC]

@rfree: żartuję przecież :(

[wytrzzeszcz]

@rfree: czo te buffory to ja nawet nie

[KrzaQ2]

@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 :) )

C pozwala na zbyt wiele, aby statyczna analiza

[wawero]

@rfree: na linuxy nie wykrywa się tylu błędów ponieważ jest mniej popularny i jest więcej różnych dystrybucji ;)

[pingwindyktator]

@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]

@pingwindyktator: a co wtedy z apkami, które oczekują const char*? Imo, z reguły takie kwiatki są efektem utrzymywania wstecznej kompatybilności.

[pingwindyktator]

@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 ;|

[calka]

@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,

[rfree]

@calka dziś widziałem właśnie błąd pamięci taki ;)

@pingwindyktator: ( ͡°( ͡° ͜ʖ( ͡° ͜ʖ