N

iewiele osób zdaje sobie sprawę z faktu, że polecenie ldd służące do wyświetlania bibliotek współdzielonych wymaganych przez dany program nie jest plikiem binarnym tylko skryptem w języku bash:

agresor@darkstar:~$ whereis ldd
ldd: /usr/bin/ldd /usr/share/man/man1/ldd.1.gz
agresor@darkstar:~$ file /usr/bin/ldd
/usr/bin/ldd: Bourne-Again shell script, ASCII text executable

W dodatku, jeśli przeczytamy stronę manualną tego polecenia natchniemy się na taki zapis:

Należy pamiętać, że w pewnych okolicznościach (np. gdy program określa interpreter ELF inny niż ld-linux.so), niektóre wersje ldd mogą próbować uzyskać informacje o zależnościach, próbując bezpośrednio wykonać program, co może doprowadzić do wykonania dowolnego kodu zdefiniowanego w interpreterze programu ELF, a być może do wykonania samego programu (w wersjach glibc 2.27, implementacja upstream ldd na przykład to robiła, chociaż większość dystrybucji dostarczała zmodyfikowaną wersję, która tego nie robiła).

Dlatego nigdy nie należy używać ldd na niezaufanym pliku wykonywalnym, ponieważ może to spowodować wykonanie dowolnego kodu.

Zapis ten znajduje swoją historię w CVE-2009-5064, czyli luce w sposobie, w jaki narzędzie ldd identyfikowało biblioteki dołączane dynamicznie. Jeśli osoba atakująca mogłaby nakłonić użytkownika do uruchomienia ldd na złośliwym pliku binarnym, mogłoby to spowodować wykonanie dowolnego kodu z uprawnieniami użytkownika uruchamiającego ldd. Przykłady takich aplikacji mogą zostać stworzone np. za pomocą osobnej biblioteki C do tworzenia wbudowanych systemów Linux. Wystarczy zlinkować szkodliwy kod z nowym programem ładującym, z którego usuniemy / zakomentujemy wykrywanie zmiennej LD_TRACE_LOADED_OBJECTS:

/*
   if (_dl_getenv("LD_TRACE_LOADED_OBJECTS", envp) != NULL) {
           trace_loaded_objects++;
   }
*/

Spowoduje to, że szkodliwy program zostanie uruchomiony przez program ładujący nawet, jeśli narzędzie systemowe ustawi taką zmienną. Teraz w samym programie należy wykrywać w/w zmienną, aby uzależnić od niej wersję uruchomionego kodu:

#include <stdio.h>
#include <stdlib.h>

int main()
{
   /* wykrycie uruchomienia ldd */
   if (getenv("LD_TRACE_LOADED_OBJECTS") != 0) {
      printf("szkodliwy kod\n");
      printf("\tlibc.so.6 => /lib/libc.so.6 (0x4001d000)\n");
      printf("\t/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)\n");
      return 0;
   }

   printf("normalny kod\n");
   return 0;
}

Jak widzimy nie do końca jest bezpieczne uruchamianie ldd na niezaufanych plikach binarnych. Skrypt ldd używa dynamicznego linkera do załadowania pliku binarnego i jego zależności do pamięci, a następnie polega na samym dynamicznym konsolidatorze, aby wyświetlić szczegóły w konsoli. Z tego powodu proces ten może być nadużywany w inny sposób niż zgodnie z przeznaczeniem np. do wstrzyknięcia kodu, jak było to w przypadku CVE-2019-1010023. W jaki więc sposób sprawdzać zależności? Oczywiście nieznane pliki binarne powinny być sprawdzane na specjalnie przygotowanym do tego środowisku. Po drugie możemy skorzystać bezpośrednio z linkera systemowego:

agresor@darkstar:~$ /lib64/ld-linux-x86-64.so.2 --verify /bin/ls \
                    && echo 'Plik obsługiwany!' || echo 'Plik nieobsługiwany!'

Jeśli plik jest obsługiwany, możemy go sprawdzić za pomocą składni:

agresor@darkstar:~$ LD_TRACE_LOADED_OBJECTS=1 /lib64/ld-linux-x86-64.so.2 /bin/ls
	linux-vdso.so.1 (0x00007ffe3b1dd000)
	libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f4b1111f000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f4b10ef7000)
	libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x00007f4b10e60000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f4b11177000)

No i proszę. Otrzymujemy dokładnie taki sam wynik, jaki wytworzyłby skrypt ldd (minus różnice w adresach pamięci pod którymi zostały załadowane biblioteki, ale to ze względu na ASLR).

Więcej informacji: ldd(1) and untrusted binaries, Compromising analysis tools, ldd can execute an app unexpectedly, The GNU C Library version 2.27 is now available

J

ak zostało to wspomniane we wcześniejszym wpisie – w wersji Linuksa v3.14 został wprowadzony mechanizm Kernel Address Space Layout Randomization. Wiele dystrybucji od jakiegoś czasu i tak zdecydowało o włączeniu KASLR dlatego od wersji v4.12 jądra Ingo Molnar podjął decyzję o jego aktywacji w standardowej konfiguracji. Oznacza to, że kod jądra będzie losowo umieszczany w pamięci RAM przy każdym starcie systemu:

# 1'wsze uruchomienie
root@darkstar:~# cat /proc/kallsyms | grep ' commit_creds\| prepare_kernel'
ffffffff8109eb60 T commit_creds
ffffffff8109ee40 T prepare_kernel_cred
# 2'gie uruchomienie
root@darkstar:~# cat /proc/kallsyms | grep ' commit_creds\| prepare_kernel'
ffffffffaa0a3bd0 T commit_creds
ffffffffaa0a3fc0 T prepare_kernel_cred

Na temat efektywności tego rozwiązania wypowiedział się Brad Spengler z PaX Team. Warto również zapoznać się z prezentacją Black Hat – “Breaking Kernel Address Space Layout Randomization (KASLR) With Intel TSX”. Dlatego rozwiązanie to należy traktować jako jedną z wielu warstw do ochrony systemu.

Więcej informacji: Kernel address space layout randomization

P

anowie z osławionego błędu związanego z GRUB2 ujawniają bardzo proste obejście mechanizmu ASLR. Każdy użytkownik, który mógł uruchomić aplikacje 32-bitowe na maszynie x86 – mógł za pomocą prostego polecenia wydanego z poziomu powłoki bash (ulimit -s unlimited) wyłączyć mechanizm Address Space Layout Randomization. Nie jest to luka sama w sobie, ale prosty i bardzo stary trik, jak obejść mechanizm dodatkowego zabezpieczenia, aby ułatwić sobie eksplorację innego błędu.

Więcej informacji: CVE-2016-3672 – Unlimiting the stack not longer disables ASLR

O

d wersji jądra 2.6.12 (w innych dystrybucjach jak np. CentOS poszczególne patche mogą być aplikowane do niższych wersji) włączony jest mechanizm ASLR – Address Space Layout Randomization, czyli Losowe Ułożenie Przestrzeni Adresowej, który umożliwia wprowadzenie losowości do schematu adresowania danych procesu, które ładowane są do pamięci. Oznacza to, że ASLR może ulokować położenie kodu wykonalnego, bibliotek, sterty oraz stosu w losowych pozycjach przestrzeni adresowej procesu. Utrudnia to przewidywanie przez atakujący program adresu następnych instrukcji i zabezpieczenie systemu przed atakami typu ret2libc.
[ czytaj całość… ]