Przepełnienie bufora x monkeyuser.com

monkey-user-coffee-overflow

 

Każdy lubi gorącą kawę… dopóki mieści się w filiżance! W przeciwnym razie, w momencie gdy zaczyna się przelewać, zamienia się w groźną ciecz, która pozostawia dużo bałaganu, a ty nie jesteś w nastroju do sprzątania.

 

Z aplikacjami jest dokładnie tak samo. Lubimy nasze dane w miejscu, w którym być powinny: długość zgodna z ich przeznaczeniem, bez nadpisywania innych danych, co mogłoby spowodować nieoczekiwane rezultaty.

 

 

Nie daj się oszukać, nie tylko w Prima Aprilis. Przeczytaj do końca i poznaj nasze wskazówki dot. bezpieczeństwa aplikacji.

Zadbaj o to, żeby aplikacje, które tworzysz były bezpieczne. Zorganizuj warsztaty Secure Aware Developer w swojej firmie

 

 

Zacznijmy od krótkiej lekcji historii i robaka Morris, jednego z pierwszych tego typu. W popularnej wersji usługi finger, używanej do wymiany informacji o systemach komputerowych i ich użytkownikach, wykorzystano lukę przepełnienia bufora. Ten incydent w 1988 odciął 10% internetu na świecie. Obroniła się Finlandia, która nie miała wtedy połączenia z internetem.

 

Inny znany robak – SQL Slammer – pochodzi z 2003 roku. Wykorzystał problem przepełnienia bufora w Microsoft SQL Server i Desktop Engine. Błąd został znaleziony 6 miesięcy wcześniej i pomimo tego że została opublikowana poprawka bezpieczeństwa, to nie została ona wdrożona przez wiele organizacji. SQL Slammer zainfekował 75000 ofiar w ciągu 10 minut.

 

Heartbleed to kolejny interesujący przypadek, który nie jest do klasycznym przepełnieniem bufora, a raczej tak zwanym nadczytaniem (buffer over-read), co oznacza, że program kontynuuje czytanie danych dalej niż tego oczekujemy. Dzięki temu możliwe było uzyskanie dostępu do pamięci serwera www i przykładowo uzyskanie danych POST od innych użytkowników. Zobacz przykład.

 

A co w przypadku przepełnienia licznkika, który jest liczbą całkowitą? Wyobraź sobie licznik kilometrów, który wskazuje same 9. Co wskaże po kolejnym kilometrze? Zgadza się – ponownie same 0. Jeśli interesuje cię prawdziwy scenariusz: warto przeczytać.

 

 

Jak zadbać o bezpieczeństwo:

  • Jeśli twój program jest napisany w języku silnie typowanym, który nie pozwala na bezpośredni dostęp do pamięci takim jak np. Java, .NET lub Phyton to prawdopodobnie nie będziesz miał problemów z przepełnieniem bufora. Oczywiście istnieją pewne wyjątki (np. jeśli używasz rozszerzeń z podatnościami), ale w typowym przypadku nie musisz się o nie martwić
  • W przeciwnym razie pamiętaj o używaniu bezpiecznych funkcji, które sprawdzają granice bufora (wspomniany robak Morris wykorzystywał niebezpieczną funkcję gets w fingerd)
  • Może wykorzystać również techniki takie jak Stack Canary
  • Zawsze sprawdzaj dane wejściowe!
  • Zleć profesjonalne testy bezpieczeństwa twojej aplikacji i usuń możliwe wektory ataków resource overflow i innych.

 

Jak widać, problem przepełnienia bufora jest bardzo prosty do naprawienia, ale jeśli twoja filiżanka do esspresso ma 30ml to lepiej sprawdź ustawienia ekspresu! Inaczej możesz skończyć z kawą na swoich butach…

 

Pamiętaj – walidacja danych wejściowych jest tylko (i aż) pierwszą linią obrony, nie tylko przeciwko atakom buffer overflow.

 

 

Subskrybuj nasz newsletter i bądź na bieżąco!

 

Śledź nas na Twitter | Medium | Facebook | LinkedIn | GitHub

 

Materiał powstał we współpracy z monkeyuser.com

Bądź na bieżąco!

  • Artykuły i raporty
  • Narzędzia
  • Nasze prezentacje i relacje z konferencji na całym świecie
Podanie danych jest dobrowolne. Będziemy wysyłać newsletter do czasu cofnięcia zgody (Możesz cofnąć zgodę w każdym czasie). Dane będą przetwarzane przez okres czasu wskazany w Polityce Prywatności dostępnej pod adresem URL.
Administratorem danych jest SecuRing S.J. z siedzibą ul. Kalwaryjska 65/6, 30-504 Kraków. Mam prawo cofnąć zgodę w każdym czasie (można bezpośrednio kliknąć w e-mailu z newslettera lub wysłać informację na adres e-mail info@SecuRing.pl lub pod numerem telefonu: 12 425 25 75). Mam prawo dostępu do danych, sprostowania, usunięcia lub ograniczenia przetwarzania, prawo sprzeciwu, prawo wniesienia skargi do organu nadzorczego i prawo do przeniesienia danych. Podstawą prawną do przetwarzania danych osobowych jest art. 6 ust.1 lit. a) rozporządzenia o ochronie danych osobowych (RODO).
Administrator korzysta z różnych rozwiązań informatycznych, które pozwalają na sprawniejszą komunikację oraz wysyłkę newslettera (te firmy są tzw. odbiorcami danych/procesorami). Dane nie są przekazywane poza Europejski Obszar Gospodarczy. Firmy te mają podpisane stosowne umowy powierzenia przetwarzania danych osobowych.
Dziękujemy za zapisanie się do newslettera.
Wystąpił problem z przesłaniem wiadomości.
Prosimy o kontakt telefoniczny.