Strona 1 z 5 123 ... OstatniOstatni
Pokaż wyniki 1 do 10 z 46

Temat: Exploit / Shellcode dla modułu jądra Linux 2.6

  1. #1

    Lightbulb Exploit / Shellcode dla modułu jądra Linux 2.6

    Mamy podatny moduł jądra (akademicki). Występuje w nim prosty buffer overflow.
    Można wstrzyknąć adres kodu powłoki. Wywołanie kończy się oopsem - bad eip address.

    Jak exploitować błędy tego typu w kernel mode? Proste przekazanie adresu kodu
    powłoki w przestrzeni adresowej zwykłego procesu działającego w user mode
    kończy się niepowodzeniem.

    Gdzie możemy wstrzyknąć kod, aby moduł jądra poprawnie go wykonał?
    Będę wdzięczny za jakiekolwiek konkretne linki, poc'e, info.
    Odsyłacze do google możecie darować

    Kilka dodatkowych informacji, uprzedzając pytania:

    1. Działa podatny moduł, który exploitujemy.
    2. Działa aplikacja user space, która alokuje sobie shellcode w pamięci i czeka.

    Przekazuję adres do kodu powłoki (2) do modułu (1) wykorzystując BO.
    Dostaję oopsa - bad eip address. Adres jest błędny z punktu widzenia kernela.

    Pkt 2. wykonuję w taki sposób, bo nie znam innej możliwości przekazania kodu do przestrzeni
    adresowej jądra, aby wykonać shellcode. I tego właśnie dotyczy pytanie. O ile się domyślam,
    jądro nie ma dostępu do segmentów procesów user mode... tak to wygląda z mojego
    punktu widzenia. Ograniczonego do wiedzy nie-kernelowej i typowych przypadków
    aplikacyjnych. Stąd pytanie - JAK to się robi w trybie jądra.

    -
    thx, dyb
    Ostatnio edytowane przez dyb : 05-22-2009 - 23:13

  2. #2

    Domyślnie

    Jak widzę jest to przepełnienie na stosie (nadpisywana kopia EIP). Ale kopia EIP jest zapisywana złym adresem i shellcode nie zostaje wykonany. Ja sprawdziłbym jakim adresem został nadpisany EIP (komenda dmesg jeżeli był crash). Może kernel ma randomizacje adresow? Nie wiem dokładnie nie jestem specjalistą w tych sprawach.
    "a imię jego będzie czterdzieści i cztery"
    A. Mickiewicz Dziady cz. III

  3. #3

    Domyślnie

    rafal44, przekazuję poprawny adres do kodu powłoki. Bad EIP address
    dotyczy dokładnie tego adresu, który przekazuję, więc pod tym kątem
    wszystko jest ok. Chodzi o to, że dla jądra ten adres wydaje się
    niepoprawny. Randomizacja va space wyłączona - pomijamy.

    Sugestie?

  4. #4
    Zarejestrowany
    Jun 2006
    Skąd
    rand(.eu)
    Postów
    8,748

    Domyślnie

    Rozumiem, ze sprawdzales zwykly overflow w userland i dzialal a w kernel-mode nie dziala. Czesto nawet jak wylaczysz ASLR to i tak dziala - takie moje doswiadczenie w tym zakresie. Architektura 32bit czy cos innego?

    ret2libc?
    ctrl-alt-del.cc - soft reset site for IT admins and other staff :-)

  5. #5

    Domyślnie

    TQM, shellcede jest ok, w us działa. ASLR na pewno jest wyłączony.
    Architektura ia32.

    BTW okazało się, że przekazywałem błędny adres, ale mimo poprawek pojawia się kłopot typu:
    unable to handle kernel paging request at fffffffx i bad eip value. Zupełnie nie wiem, skąd
    fffffffx. Przekazuję adres shellcode z aplikacji (0x080496xx). Aha, nie ma w nim bajtów
    zerowych.

    Rozumiem, że jądro nie ma dostępu do zew. stosów. Ale wg mojego wyobrażenia
    powinno mieć dostęp do innych regionów działających procesów. Jakkolwiek, udało mi się
    odpalić "coś", bo system się... zawiesił.

    TQM, inne sugestie?

  6. #6
    Zarejestrowany
    Jul 2008
    Skąd
    Za twoimi plecami
    Postów
    351

    Domyślnie

    Myślę, że przydałby się nam kod źródłowy tego modułu. Ułatwiłoby to rozważania...

    EDIT: No i kod shellcode'u, którego używasz...
    Black Coders | Hacking, Kernel, Linux, Operating Systems, Programming
    I otworzyła studnię Czeluści,
    a dym się uniósł ze studni jak dym z wielkiego pieca,
    i od dymu zaćmiło się słońce i powietrze.
    A z dymu wyszła szarańcza na ziemię,
    i dano jej moc jaką mają ziemskie skorpiony.
    (...)
    I dano jej nakaz aby nie zabijała,
    lecz aby przez pięć miesięcy cierpieli katusze...

  7. #7
    Zarejestrowany
    Jun 2006
    Skąd
    rand(.eu)
    Postów
    8,748

    Domyślnie

    Ormi... kodu modulu sadze nikt z nas nie dostanie ze wskazaniem gdzie jest blad, tym bardziej exploita do niego...

    To ze sie zawiesil komp to znaczy ze cos zadzialalo, ale nie wiesz do konca co. Zakladam ze to Twoja maszyna i masz na niej root'a tak czy inaczej, wiec pozostaje tylko probowac - na razie nie mam zadnych innych pomyslow.

    Co do zmiany EIP - dostales bad EIP i inny adres niz podales. Czy ten kernel ma jakies latki dodane?
    ctrl-alt-del.cc - soft reset site for IT admins and other staff :-)

  8. #8
    Zarejestrowany
    Jul 2008
    Skąd
    Za twoimi plecami
    Postów
    351

    Domyślnie

    A więc tak:
    1. Kod modułu by się przydał, gdyż jeśli moduł robi coś w rodzaju:
    copy_from_user(buf_od_usera, buf_docelowy, 100000);
    A buf_docelowy ma na przykład 4096 bajty, to można shellcode umieścić w buforze i w dodatku nie martwić się o bajty zerwoe występujące w shellcode. Jeśli użyta jset funckja strcpy, to wtedy nie może być bajtów zerowych w shellcodzie.
    2. Shellcode nie może być taki jak dla aplikacji user mode. Musi robić coś w rodzaju:
    Kod:
    current->parent->uid = 0;
    current->parent->euid = 0;
    current->parent->gid = 0;
    current->parent->egid = 0;
    Do tego dochodzi problem wersji jądra. W kernelu >= 2.6.29 struktura task_struct(current jest tą strukturą, tak samo jak current->parent) nie ma pól uid, euid itp. Są one w strukturze cred, która jest częścią task_struct. W związku z tym powyżej przedstawiona część shellcode'u nie zadziała. W dodatku aby zmienić wartości tych pól potrzeba funkcji prepare_creds i commit_creds. Przykład:
    Kod:
    struct cred *new = prepare_creds();
    new->uid = new->euid = 0;
    new->gid = new->egid = 0;
    commit_creds(new);
    Funkcja prepare_creds zwraca wskaźnik do struktury creds aktualnego procesu, a trzeba zmienić wartości uid, gid itp. dla rodzica, gdyż proces exploitujący zostanie zabity przez jądro.
    Tzn, że aby uzyskać prawa roota exploit musi robić coś takiego:
    Shellcode jest przechowywany w pewnym buforze. Proces główny tworzy funkcją fork proces potomny. Proces potomny wykorzystuje buffer overflow "wysyłając" do jądra takie dane, żeby shellcode znalazł się w buforze jądra(buf_docelowy) a kopia EIP została nadpisana adresem tego bufora. W efekcie zostanie wykonany kod shellcode'u. Jądro zabije potomka, ale wcześniej zwiększono przywileje procesu rodzica. Rodzic odpala powłokę - mamy roota. Uff...

    Coż, przed tobą niełatwe zadanie. Musisz stworzyć shellcode opierający się na moim fragmencie, w przypadku niemożności występowania bajtów zerowych wyeliminować je z kodu shellcode, wyciągnąć coś sensownego z mojego powyższego bełkotu, poprawić ewentualne błędy merytoryczne powyższego opisu(w końcu nie jestem nieomylny) napisać exploita, uruchomić i modlić się, żeby zadziałał.
    Co gorsza nie jestem pewny jak skompilować shellcode tak, żeby jego kod dało się "wstrzyknąć".
    Good luck

    EDIT:
    O, już chyba wiem:
    kompilujesz:
    Kod:
    #include <linux/shed.h>
    
    void shellcode(void)
    {
    current->parent->uid = 0;
    current->parent->euid = 0;
    current->parent->gid = 0;
    current->parent->egid = 0;
    }
    Jako moduł jądra. Jak by co MAkefile:
    Kod:
    obj-m += shellcode.o
    all:
    	make -C /lib/modules/$(shell uname -r)/build M=${PWD} modules
    clean:
    	make -C /lib/modules/$(shell uname -r)/build M=${PWD} clean
    objdump -d shellcode.ko
    W wyniku znajdują się hexy funkcji shellcode. Kopijuesz je i to one są wstrzykiwanym kodem.
    Ostatnio edytowane przez Ormi : 05-25-2009 - 18:52
    Black Coders | Hacking, Kernel, Linux, Operating Systems, Programming
    I otworzyła studnię Czeluści,
    a dym się uniósł ze studni jak dym z wielkiego pieca,
    i od dymu zaćmiło się słońce i powietrze.
    A z dymu wyszła szarańcza na ziemię,
    i dano jej moc jaką mają ziemskie skorpiony.
    (...)
    I dano jej nakaz aby nie zabijała,
    lecz aby przez pięć miesięcy cierpieli katusze...

  9. #9
    Zarejestrowany
    Jun 2006
    Skąd
    rand(.eu)
    Postów
    8,748

    Domyślnie

    Ormi++

    Fajny opisik, tylko mnie ciagle zastanawia jedno - mamy modul kernela, ktory i tak dziala z najwyzszymi uprawnieniami, wiec w userland bedzie to jakby exploitowac aplikacje suid-root. Problemem nie jest kwestia uprawnien ale samo ustawienie wlasciwego adresu - EIP zwrocony w bledzie nie zgadza sie z tym ktory zostal podany z shellcode :-/
    Nadal wydaje mi sie ze w omawianym problemie cos w kernelu robi relokacje obszarow pamieci... tylko nie wiem niestety co :-/
    ctrl-alt-del.cc - soft reset site for IT admins and other staff :-)

  10. #10

    Domyślnie

    1. Ponawiam prośbę o przedstawienie kodu modułu (lub fragmentu);
    Będziemy mieli wtedy więcej informacji o tym co dzieje się z buforem.

    2. Spróbowałbym techniki return to libc jak wspominał TQM. Wtedy dowiesz się czy kernel uznaje EIP za błędny, czy to coś innego powoduje crash. Funkcja z dozwolonych obszarów pamięci powinna zostać wywołana.

    I tak mi się teraz przypomniało shellcode powoduje bałagan w pamięci, więc jeżeli shellcode nie zadziała poprawnie, proces dalej kontynuuje działanie i występuje crash. Przykład: nie udało się uruchomić powłoki przez funkcję z rodziny exec, proces dalej wykonuje pracę.Pobiera błędne wartości rejestrów ze stosu i wiadomo co dalej.
    "a imię jego będzie czterdzieści i cztery"
    A. Mickiewicz Dziady cz. III

Strona 1 z 5 123 ... OstatniOstatni

Podobne wątki

  1. Backdoor w pakiecie .deb jądra
    By Deathgazer in forum Wirusy/Konie trojańskie
    Odpowiedzi: 0
    Autor: 05-18-2009, 19:25
  2. Moduły jądra
    By Ormi in forum Linux
    Odpowiedzi: 7
    Autor: 01-05-2009, 18:21
  3. win32 shellcode
    By naichniach in forum Off Topic
    Odpowiedzi: 5
    Autor: 12-01-2007, 12:38
  4. problem po wciśnięciu modułu dll
    By Neghe in forum Wirusy/Konie trojańskie
    Odpowiedzi: 0
    Autor: 05-02-2007, 20:16

Tagi

Zasady Postowania

  • Nie możesz zakładać nowych tematów
  • Nie możesz pisać wiadomości
  • Nie możesz dodawać załączników
  • Nie możesz edytować swoich postów
  •  
Subskrybuj