1 / 60

Błędy implementacji oprogramowania

Błędy implementacji oprogramowania. Przemysław Targalski, Krzysztof Szcześniak. Błędy implementacji oprogramowania. Błędy implementacji oprogramowania, to takie które popełnia nieświadomie programista, a z którymi skutkami musi najczęściej zmierzyć się administrator.

gallia
Télécharger la présentation

Błędy implementacji oprogramowania

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Błędy implementacji oprogramowania Przemysław Targalski, Krzysztof Szcześniak

  2. Błędy implementacji oprogramowania Błędy implementacji oprogramowania, to takie które popełnia nieświadomie programista, a z którymi skutkami musi najczęściej zmierzyć się administrator.

  3. Rodzaje błędów implementacji • Buffer Overrun (przepełnienie bufora) • Nieprawidłowe zarządzanie pamięcią • Nieprawidłowa obróbka danych uzyskanych od użytkownika: • Format Strings w C (Ciągi formatujące) • Błędy aplikacji WWW • XSS • CSRF • SQL Injection

  4. Buffer overrun • buffer overrun - błędy polegające na kontrolowanym nadpisywaniu przestrzeni adresowej procesu (np. stosu lub sterty) danymi, mogącymi zmienić przebieg wykonania procesu, np. poprzez modyfikację adresu powrotu funkcji lub wskaźnika do innej funkcji.

  5. Buffer overrun • Wpisywanie większej ilości danych niż jest w stanie przechować bufor • Off-by-one error – wpisanie wartości pod n-tym indeksem w n-elementowej tablicy • Najbardziej narażone języki – C, C++ • Bezpieczne języki – Java, C#

  6. Buffer overrun • Stack-based Overflows ( stack smashing ) – nadpisywanie danych na stosie • Heap-based Overflows – nadpisywanie danych na stercie

  7. Stack-based Overflows • void overflow_function (char *str) { char buffer[20]; strcpy(buffer, str); }

  8. Stack-based Overflows • Jeżeli bufor jest dostatecznie duży można go zapełnić złośliwym kodem, a do adresu powrotu wpisać adres tego bufora.

  9. Stack-based Overflows • strcpy( char* dest, const char* src ); • strcat( char* dest, const char* src ); Obie funkcje zakładają że bufor dest ma wystarczający rozmiar aby zmieścić kopiowane dane. • sprintf() char buffer[512];sprintf(buffer, "Wrong command: %s\n", user);

  10. Stack-based Overflows • Rozwiązanie (1) – dynamiczna alokacja pamięci: dest = (char *)malloc(strlen(source) + 1); if (dest) { strcpy(dest, source); } else { /* Błąd alokacji pamięci */ … } • Rozwiązanie (2) – bezpieczne odpowiedniki: strcpy_s( char*dest, size_t sizeInBytes, const char* source); strcat_s( char*dest, size_t sizeInBytes, const char* source);

  11. Stack-based Overflows • gets(char* buffer); - pobiera dane ze standardowego wejścia. • Bezpieczne odpowiedniki: gets_s(buffer, sizeof(buffer)); fgets (buffer, sizeof(buffer), stdin);

  12. Stack-based Overflows Sposoby ochrony: • Non-Executable Stacks • Address space layout randomization • Runtime Bounds Checkers • Canaries • StackGuard • Stack Smashing Protector (ProPolice) • Libsafe and LibVerify

  13. Non-Executable Stacks • Zakaz wykonywania instrukcji znajdujących się na stosie lub stercie. • Blokada wykonywania istnieje od procesora 80286 na poziomie segmentów jednak nie przyjęła się. • Bity NX ("No eXecute„ - AMD) lub XD ("eXecute Disabled„ - Intel) – blokada na poziomie stron pamięci. Używane dopiero w Windows XP sp2 (Data Execution Prevention ) Exec Shield – patch dla linuxa • Nie uchroni przed atakami korzystającymi z bibliotek systemowych np „return-to-libc attack”

  14. Address space layout randomization • Losowy rozkład przestrzeni adresowej • Dostarcza środków do wprowadzenia losowości do schematu adresowania wszystkich danych, które są ładowane do pamięci.

  15. Runtime Bounds Checkers • C++ standardowo nie posiada takiej możliwości • DevPartner for Visual C++

  16. Canaries • „Kanarki” – pewne informacje dodane pomiędzy buforem a ważnymi danymi np. adresem powrotu – jeżeli zostaną zmienione wiemy, że nastąpiło przepełnienie bufora. • Terminator canaries • Random canaries • Random XOR canaries

  17. Canaries

  18. StackGuard • Dodatek do kompilatora gcc 3.x • Dodaje własny kod do każdej funkcji • Używa „kanarka” obok adresu powrotu funkcji • Przed powrotem z funkcji sprawdza poprawność „kanarka”

  19. Stack Smashing Protector (ProPolice) • Dodatek do gcc 3.x • Stworzony przez IBM, oparty na StackGuard • Używany w m.in. w OpenBSD • Możliwość użycia w gentoo po dopisaniu „hardened” do USE flags

  20. Libsafe and LibVerify • Biblioteka wykrywająca przepełniania buforów w programach. Jest dołączana w sposób dynamiczny – nie trzeba nic rekompilować. • Przechwytuje wywołania niebezpiecznych funkcji (strcpy() itp.) i sprawdza czy nie nastąpiło przepełnienie, jeśli nastąpiło alpikacja jest zabijana.

  21. Heap-based Overflows • Trudniejsze do wykrycia • Zależą od rodzaju danych zapisanych w pamięci • Podmiana informacji takich jak uprawnienia użytkownika lub ścieżki dostępu do pliku.

  22. Heap-based Overflows • #include <stdio.h> • #include <stdlib.h> int main(int argc, char *argv[]) { FILE *fd; // Allocating memory on the heap char *userinput = malloc(20); char *outputfile = malloc(20); strcpy(outputfile, "/tmp/notes"); strcpy(userinput, argv[1]); fd = fopen(outputfile, "a"); if (fd == NULL) { fprintf(stderr, "error opening %s\n", outputfile); exit(1); } fprintf(fd, "%s\n", userinput); fclose(fd); return 0; }

  23. Heap-based Overflows Sposoby ochrony: • DieHard • Electric fence

  24. DieHard • Praktycznie eliminuje możliwość przepełnienia bufora na stercie. • Alokuje obiekty losowo w pamięci, zdala od siebie • Eliminuje błędy związane z podwójną dealokacją tego samego obszaru pamięci.

  25. Electric fence • Biblioteka która po podlinkowaniu do programu przejmuje kontrolę nad zarządzaniem pamięcią. • Eliminuje możliwość nadpisania jednego bufora innym. • Każdy bufor jest alokowany na innej stronie. Wyjście poza bufor automatycznie zabija aplikację.

  26. Buffer overrun • Niewykorzystane dziury Microsoft Security Bulletin MS04-028 Buffer Overrun in JPEG Processing (GDI+) Could Allow Code Execution (833987) Microsoft Security Bulletin MS03-023 Buffer Overrun In HTML Converter Could Allow Code Execution (823559)

  27. Buffer overrun • Code Red – robak infekujący IIS GET /default.ida?NNNNNNNNNNNNNNNNNNNNNNNNN NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN NNNNNNNNNNNNNNNNNNN %u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801 %u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3 %u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a HTTP/1.0

  28. Buffer overrun • Blaster (2003)– wykorzystał dziurę w DCOM RCP – powodował restart komputera po ok. 60 sekundach od połączenia z internetem. • Sasser (2004) – dziura w Local Security Authority Subsystem Service – losowe restarty komputera.

  29. Format Strings w C • Częsty błąd przy wyświetlaniu tekstu gdy nie trzeba go formatować: char tekst[100]; fgets (tekst, sizeof(tekst), stdin); tekst[sizeof(tekst)-1]=‘\0’; printf(tekst); // źle printf(”%s”,tekst); //dobrze

  30. Format Strings w C • Czy aby na pewno printf() tylko wyświetla? • %s – wyświetlanie łańcucha danych • %n – zapis ilości wypisanych do tej pory znaków pod wskazany adres w pamięci. • %d – wyświetlanie liczby całkowitej • %20d – wyświetlanie liczby całkowitej i ustawienie szerokości na 20 znaków (co pozwala dowolnie modyfikować ilość wyświetlonych znaków)

  31. Zarządzanie pamięcią • Alokacja pamięci na typ/obiekt reprezentujący dany zasób • Inicjalizacja obiektu reprezentującego zasób - doprowadzenie go do stanu gotowości do użycia (utworzenie połączenia sieciowego, otwarcie pliku, wypełnienie buforów itp.) • Użycie (być może wielokrotne) zasobu reprezentowanego przez obiekt. • Zakończenie wykorzystania zasobu (zamknięcie połączenia sieciowego, zamknięcie pliku, opróżnienie buforów itp.) • Zwolnienie pamięci przydzielonej na obiekt reprezentujący zasób.

  32. Zarządzanie pamięcią C/C++ kontra Java/.Net • W językach C/C++ jesteśmy zmuszeni do samodzielnego wykonania wszystkich powyższych czynności • Platforma Java/.Net zwalnia programistę z części tych punktów: • Automatyczna alokacja pamięcie (punkt 1) • Automatyczne oczyszczanie z niepotrzebnych obiektów(5) • Wiele typów zasobównie wymaga żadnych dodatkowych zabiegów związanych z ich zwalnianiem(4)

  33. Alokacja pamięci a typy • Typy bezpośrednie(dziedziczą po System.ValueType), alokowane są na stosie, a zwalnianie pamięci odbywa się automatycznie • Typy referencyjne (dziedziczą po System.Object ), alokowane są na stercie. W momencie uruchomienia tworzony jest wskaźnik alokacji (AllocPnt), pokazujący na adres w pamięci, pod którym zostanie utworzony następny obiekt.

  34. Kiedy wywołujemy operator new : Sprawdzana jest wolna przestrzeń na stercie jeśli nie ma wystarczająco dużo miejsca - obszar sterty jest powiększany lub wykonywane jest jego porządkowanie - o tym w dalszej części artykułu jeśli wolny obszar sterty jest odpowiednio duży, środowisko uruchomieniowe wywołuje konstruktor klasy tworzonego obiektu, a operator new zwraca obiekt nowo utworzonego obiektu (równy aktualnej wartości AllocPnt) wartość wskaźnika AllocPnt zwiększana jest o wielkość pamięci przydzieloną nowo utworzonemu obiektowi Sterta

  35. Sterta c.d. Po utworzeniu kilku obiektów sterta mogłaby wyglądać tak: W przypadku braku miejsca a czyszczenie i powiekszanie pamięci nie daje rezultatów otrzymujemy wyjątek OutOfMemoryException.

  36. Alokacja pamięci w C/C++ • Wolne obszary stery zapisywane są pod postacią listy wolnych obszarów • Kosztowna alokacja nowych bloków • wymaga przejrzenia listy wolnych bloków • znalezienia bloku o odpowiedniej wielkości • zmodyfikowania listy wolnych bloków tak, aby uwzględniała nowo zajęty obszar pamięci.

  37. Alokacja pamięci .Net • Prostsza i szybsza niż w C/C++ gdyż wymaga jedynie inkrementacji jednego wskaźnika o odpowiednią wartość • Otrzymujemy porównywalną szybkość alokacji pamięci na stosie jak i na stercie

  38. Garbage Collector • Skutkiem tak bezpotroskiego zajmowania pamięci było by jej szybkie zaśmiecienie. Za odśmiecenie odpowiada gc. • GC może sam zwolnić niepotrzebny obiekt, ale nie potrafi wykorzystanych przez niego niezarządzonyc zasobów (np. otwartych plików, połączeń sieciowych) – to trzeba samemu zaimplementować

  39. Finalizator klasy • Instrukcje, jakie GC ma wykonać podczas tworzenia obiektu : class TextClass { // finalizator klasy: ~TextClass() { //zwalnianie zasobów } }

  40. Kłopoty z finalizacją • Stworzenie obiektów z finalizatorami trwa dwa razy dłuzej niż tworzenie obiektów zarządzanych (związane z wypełnieniem przez środowisko dodatkowych struktur) • Wywołania finalizatora spowalnia proces porządkowania pamięci. • Obiekty z finalizatorem zwalniane są później niż obiekty zarządzane –przedłuża sztucznie „życie” niepotrzebnych obiektów • Nie ma gwarancji co do kolejności niszczenia obiektów

  41. Kolejność niszczenia obiektów

  42. Ręczna finalizacja • W ogólności najlepiej unikać tworzenia klas, które wymagają finalizacji. • Problem w przypadku klas korzystających z plików, bądź połączeń sieciowych • Rozwiązanie: danie możliwości ręcznego zwolnienia zasobów. • W środowisku .Net odpowiadają za to dwie metody: • close() – wywołania zwalnia wszystkie zajęte zasoby(zamyka pliki, opróżnia bufory). Jest możliwość ponownego otwarcia pliku • dispose() - jej wykonanie na stałe odbiera możliwość pracy z obiektem. Wszystkie zajęte zasoby są zwalniane, a obiekt nie nadaje się już do wykorzystania.

  43. Zarządzanie pamięcią - podsumowanie • Napisanie programu w taki sposób, żeby nie próbował on czytać bądź zapisywać pamięci mu nie przydzielonej. • Garbage Collector, któremu czasami trzeba „pomóc” w zwalnianiu zasobów. • Skutki błędnego zarządzania : • Może powodować błąd wykonania i natychmiastowe zakończenie programu • Bardzo trudne do wykrycia błędy w systemach bez ochrony pamięci

  44. Zarządzanie pamięcią – podsumowanie 2 • Wyższość Java/.Net nad C/C++ • Tworzymy obiekt w C/C++ operatorem new • Potem zwalniamy jego pamięć operatorem delete • Zatrzymujemy jednak odnośnik do tej pamięci • Utworzony inny obiekt może otrzymać zwolnioną pamięć • Program otrzymuje możliwość dostępu do tej samej pamięci, bo postrzega ją jako dwa różne rodzaje obiektów • Konsekwencja takiego działania: nieprzewidywalne zachowanie się porgramu i powstanie trudnych do wykrycia błędów. Każdy błąd systemu może być potencjalnie wykorzystany do włamania się!!!

  45. WWW-XSS • XSS (Cross Site Scripting ) nieświadome przekazywanie przez witryny internetowe złośliwego kodu. • Atak składa się : • przekazanie do aplikacji złośliwego kodu przez napastnika; • nieświadome pobranie od aplikacji złośliwego kodu przez ofiarę; kod zostaje wykonany; • dodatkowe akcje wykonywane przez atakującego.

  46. XSS • Atakujący łączy się z aplikacją po czym wysyła złośliwy kod : <SCRIPT type="text/javascript"> alert('Złośliwy kod!'); </SCRIPT> • Taki kod może być np. treścią listu na forum czy adresem email w polu nadawcy. • Aplikacja odbiera kod i zapisuje go w bazie danych • Użytkonik po zalogowaniu wchodzi na stronę i nieświadomie wyświetla jego zawartość. W yniku wyświetlenia zostaje wykonany złośliwy kod JavaScript, który przekazuje pewne dane atakującemu.

  47. Luki wykorzystywane przez XSS • aplikacja wpuszcza złośliwy kod. • aplikacja wypuszcza złośliwy kod. • przeglądarka klienta wykonuje złośliwy kod.

  48. Ataki CSRF (ang. Cross Site Request Forgeries) wykorzystują mechanizm działania protokołu HTTP. Przeglądarka stron WWW po odebraniu zasobu, konkretnie kodu HTML witryny WWW, analizuje zawartość strony i pobiera kolejno wszystkie zasoby, jakie są konieczne do poprawnego wyświetlenia strony (np. pliki stylów, pliki ze skryptami JavaScript oraz obrazy).

  49. CSRF • <IMG src="ikona.png" alt="Ikona listy wypunktowanej"> , pobrany porzez zapytanie : • GET ikona.png HTTP/1.1 • GET może odwoływać się do skryptu i przekazywać mu dodatkowe dane GET skrypt.php?imie=Jan&wiek=43 HTTP/1.1 • Umieszczenie na stronie obrazu: <IMG src="skrypt.php?imie=Jan&amp;wiek=43" alt="Ikona..."> wywołuje skrypt skrypt.php i umieszcza zmienne imie oraz wiek. • Samo wyświetlanie strony WWW może wywołać nieświadome wykorzystanie różnych skryptów.

  50. Luki wykorzystywane przez CSRF • Wykorzystuje takie same luki jak XSS czyli : • aplikacja wpuszcza złośliwy kod. • aplikacja wypuszcza złośliwy kod. • przeglądarka klienta wykonuje złośliwy kod. Różnica występuje po stronie klienta, poprzednio wykorzystywanyt był JavaScirpt, teraz protokół HTTP.

More Related