Nzall
2016-02-23 20:37:56 UTC
Kiedy patrzę na exploity z ostatnich kilku lat związane z implementacjami, widzę, że całkiem sporo z nich pochodzi z C lub C ++, a wiele z nich to ataki przepełnienia.
- Heartbleed było przepełnieniem bufora w OpenSSL;
- Niedawno znaleziono błąd w glibc, który zezwalał na przepełnienia bufora podczas rozwiązywania DNS;
to tylko te, o których myślę teraz wyłączone, ale wątpię, czy były to jedyne, które A) dotyczą oprogramowania napisanego w C lub C ++ i B) są oparte na przepełnieniu bufora.
Szczególnie jeśli chodzi o błąd glibc, przeczytałem komentarz, który stwierdza, że gdyby stało się to w JavaScript zamiast w C, nie byłoby problemu. Nawet gdyby kod był tylko skompilowany do Javascript, nie stanowiłoby to problemu.
Dlaczego C i C ++ są tak podatne na ataki przepełnienia?
Z dużą mocą przychodzi duża odpowiedzialność
[Ta odpowiedź] (http://security.stackexchange.com/questions/95245/security-implications-of-neglecting-the-extra-byte-for-null-termination-in-cc/95248#95248) i [this answer] (http://security.stackexchange.com/questions/82750/why-are-buffer-overflows-executed-in-the-direction-they-are/82846#82846) mogą być ciekawymi lekturami. Zasadniczo sprowadza się to do projektu języka i poziomu, w jakim został zaimplementowany.
@RoraΖ istnieją jednak narzędzia do kompilacji C do javascript, takie jak emscripten. http://dankaminsky.com/2016/02/20/skeleton/, mam na myśli u dołu.
Twoje pytanie jest w rodzaju „Dlaczego tylko komputery z systemem Windows otrzymują wirusy Windows?”. Ponieważ wirusy Windows są możliwe tylko na komputerach z systemem Windows. C i C ++ uzyskują luki w przepełnieniu bufora z ich zdolności do wykonywania niezaznaczonych arytmetyki wskaźników. Większość innych języków nie ma tej możliwości, a zatem nie może mieć przepełnienia bufora. Twoje pytanie również nie uwzględnia popularności tych języków. (Być może inne języki są BARDZIEJ problematyczne, ale nie są używane tak często, więc mają mniej całkowitych luk w zabezpieczeniach).
Komentarze nie służą do rozszerzonej dyskusji; ta rozmowa została [przeniesiona do czatu] (http://chat.stackexchange.com/rooms/36311/discussion-on-question-by-nate-kerkhofs-why-are-programs-written-in-c-and- c-tak).
W C ++ jednym z powodów przepełnienia bufora jest niepowodzenie we współczesnym C ++ i ignorowanie bardziej bezpiecznych koncepcji, takich jak STL. Jeśli używasz C ++ tak jak C, dostaniesz to, na co zasługujesz.
Wcześniej był genialny komentarz, który najwyraźniej został usunięty: „To dlatego, że skalpel tnie więcej niż nożyczki bezpieczeństwa”
C / C ++ jest również najczęściej używany w przypadku oprogramowania, które jest narażone na największe ryzyko i ataki.
Heartbleed był dla mnie wynikiem dwóch złych praktyk w programowaniu: 1. Użycie instrukcji goto i 2. brak standardu programowania typu „Zabroń używania instrukcji„ if ”bez nawiasów klamrowych”.W takim przypadku to się nie stanie.Brak testów jednostkowych jest prawdopodobnie kolejnym powodem ... Zgadzam się, że C i C ++ są bardziej podatne na ten atak, ponieważ są językiem dość niskiego poziomu i często to programista jest odpowiedzialny za zapobieganie złemu użyciu.