Powiązania read() z zagrożeniami

2010-07-21 16:49

Podczas warsztatów omawiających naprawę wykrytych podatności jeden temat powraca ciągle: "dlaczego powinniśmy naprawić tą podatności – to tylko funkcja read(), nie można z jej pomocą nic nadpisać…" Jeśli jesteście zmęczeni powtarzaniem w kółko tego samego zdania, że każdy zaraportowany problem i podatność muszą zostać naprawione, to ten wpis na blogu jest dla Was. Możecie go pokazać kadrze kierowniczej i programistom jako dowód poprawności Waszych twierdzeń.

Po pierwsze: każda, nawet najmniej istotna podatność musi zostać naprawiona. Koniec. Po drugie to, że wywołania funkcji typu read() nic nie nadpisują nie jest do końca prawdą. Jeśli spojrzymy na takie wywołanie z perspektywy jądra systemu operacyjnego to okaże się że w tej jednej operacji bierze udział wiele wewnętrznych struktur. Dodatkowo moduły takie jak sterowniki pamięci masowych, hardware abstraction layer, czy moduł bezpieczeństwa także alokują i modyfikują wiele zasobów. Dodajmy do tego jeszcze możliwość tworzenia plików tymczasowych co od razu pociąga za sobą możliwość sytuacji wyścigu.

W przypadku funkcji takich jak ReadFile() z Windows SDK programista musi podać rozmiar bufora (co może prowadzić do przepełnienia bufora lub innych pochodnych podatności). Jednak w językach takich jak Python nie trzeba podawać żadnego rozmiaru w przypadku wywołania readlines(). Teoretycznie więc programista nie musi się martwić alokowaniem bufora w pamięci. W praktyce jednak odczyt w ten sposób niezwykle dużych plików może przynieść wiele komplikacji i doprowadzić do wysycenia wolnych zasobów systemu. Widać więc że atak typu odmowa usług także jest możliwy w przypadku wywołania read().

Penetrowanie aplikacji webowych za pomocą błędów związanych z wywołaniem read() jest fantastyczne. Pozwala na wiele ciekawych możliwości, zwłaszcza jeśli kontroluje się nazwę obiektu. Co prawda dzisiaj jest trudniej znaleźć podatność typu …/read.php?filename=/etc/passwd niż 5 lat temu, ale nadal można mieć wiele dobrej zabawy. Nawet jeśli atakujący nie ma bezpośredniego wpływu na nazwę obiektu to może mieć wpływ na jego zawartość. To z kolei oznacza potrzebę walidowania zarówno danych wejściowych jak i wyjściowych. Niebezpieczne dane nie pochodzą tylko z żądań GET i POST. Nawet jeśli nie przychodzi nam do głowy metoda wykorzystania podatności lub nie potrafimy jej wykorzystać nie może to być powodem do nie naprawienia problemu.

Podczas przeglądu kodu należy pamiętać że operacje typu read() są często ukryte pod wieloma innymi funkcjami API lub elementami danego języka. Przykładem może być import w Pythonie i require w PHP. Takie wywołania także mogą prowadzić do podatności.

Podsumowując: wywołania read() mogą być i są niebezpieczne. Jeśli ktoś raportuje podatność związaną z wywołaniem read() to należy ją naprawić tak jak każdy inny problem. Jeśli jednak ktoś chciałby jeszcze katalog zagrożeń związany z operacją read() oto niekompletna lista:

  1. Przepełnienie (bufora)
  2. Sytuacja wyścigu
  3. Walidacja danych wejściowych i wyjściowych
  4. Wyciek informacji
  5. Wysycenie / wyciek zasobów / odmowa usługi

Blog

MS SQL Server 2005 Extended Support kończy się 12 kwietnia

Rozszerzone wsparcie dla serwera Microsoft SQL Server 2005 kończy się 12 kwietnia. To ostatni moment aby dokonać migracji do wyższej wersji.

Jeśli tego nie zrobiłeś to AVET INS może wesprzeć ...

2016-03-01 09:00, Czytaj więcej Więcej
Kiedy Flash wyginie?

Flash to jedna z tych technologii, która ma bardzo złą – i w tym wypadku całkowicie zasłużenie – reputację w obszarze bezpieczeństwa. Ta reputacja jest tak zła, że od jakiegoś czasu część ...

2016-02-11 16:45, Czytaj więcej Więcej
Krytyczna podatność w kliencie OpenSSH (CVE-2016-0777, CVE-2016-0778)

Wersje oprogramowania klienckiego OpenSSH w wersjach od 5.4 do 7.1 podatne są na atak umożliwiający wyciek pamięci oraz kradzież kluczy prywatnych. W przypadku, gdy połączenie SSH zostanie przerwane ...

2016-02-01 09:30, Czytaj więcej Więcej
Microsoft ogranicza wsparcie IE tylko do wersji 11

Microsoft przestaje wspierać starsze wersje przeglądarki Internet Explorer. Jedyną wspieraną wersją od dzisiaj jest IE 11 i wyższe. Dla wielu systemów (np. Windows 7) może to oznaczać potrzebę aktualizacji lub ...

2016-01-13 09:00, Czytaj więcej Więcej
SafeNet Day: Szyfrowanie w chmurze - prezentacja

Prezentacja Aleksandra Czarnowskiego z konferencji SafeNet Day na temat Szyfrowanie w chmurze jest już dostępna do pobrania. Zapraszamy do pobrania poniżej:

http://www.avet.com.pl/media/pdf/2015-11-02_Szyfrowanie_w_chmurze.pdf

2015-10-31 10:00, Czytaj więcej Więcej