Działanie fs.protected

nfsec.pl 1 rok temu

ocząwszy od wersji 4.19 jądra systemu Linux możliwe jest uniemożliwienie otwierania FIFO lub zwykłych plików niebędących własnością użytkownika w globalnie zapisywalnych katalogach z ustawionym sticky bit (np. /tmp). Ochronę tę można stosować osobno dla FIFO, zwykłych plików, symlinków / hardlinków poprzez odpowiednie ustawienia z poziomu sysctl. Ustawienia te oparte są na łatce HARDEN_FIFO, która znajdowała się w projekcie Openwall Solar Designera, a ich celem jest utrudnienie ataków polegających na spoofingu danych. Poniżej znajduje się krótka lista starych luk, którym można było zapobiec dzięki tej funkcji (niektóre z nich pozwalają choćby na eskalację uprawnień):

Ochrona ta jest aktywowana automatycznie, jeżeli nasz system korzysta z systemd w wersji 241 lub wyższej z wspomnianym jądrem w wersji 4.19 lub wyższej. jeżeli wersja naszego jądra Linuksa wspiera tę funkcję, ale nie używamy jeszcze systemd w odpowiedniej wersji, możemy ją aktywować samodzielnie ustawiając odpowiednie ustawienia dzięki sysctl:

sysctl -w fs.protected_fifos=1 sysctl -w fs.protected_regular=2

Przykład zapisu przez użytkownika agresor do pliku /tmp/data będącego własnością użytkownika www-data bez działania ochrony (fs.protected_regular=0):

agresor@darkstar:~$ ls -al /tmp/data -rwxrwxrwx 1 www-data www-data 0 Mar 20 19:44 /tmp/data agresor@darkstar:~$ echo inject > /tmp/data agresor@darkstar:~$ cat /tmp/data inject

Przykład zapisu przez użytkownika agresor do pliku /tmp/data będącego własnością użytkownika www-data z pierwszym poziomem ochrony (fs.protected_regular=1):

agresor@darkstar:~$ ls -al /tmp/data -rwxrwxrwx 1 www-data www-data 7 Mar 20 19:45 /tmp/data agresor@darkstar:~$ echo inject_code >> /tmp/data -bash: /tmp/data: Permission denied

Przy ustawieniu poziomu na „2” ochrona dotyczy również katalogów z ustawionym sticky bit z możliwością zapisu dla grupy. To samo tyczy się ochrony sym- i hard- linków, które w globalnie zapisywalnych katalogach umożliwiały ataki ToCToU. Częstą metodą wykorzystywania tej luki było krzyżowanie się uprawnień podczas podążania za danym dowiązaniem symbolicznym (tj. użytkownik root podążał za dowiązaniem symbolicznym należącym do innego użytkownika w systemie):

root@darkstar:~# ls -al /tmp total 8 drwxrwxrwt 2 root root 4096 Mar 20 20:56 . drwxr-xr-x 19 root root 4096 Mar 20 19:55 .. lrwxrwxrwx 1 agresor agresor 14 Mar 20 20:56 alice_mirror -> /usr/local/bin root@darkstar:~# cd /tmp/alice_mirror root@darkstar:/tmp/alice_mirror#

Tutaj również rozwiązaniem było niedopuszczenie do podążania za dowiązaniami symbolicznymi, gdy użytkownik podążający i właściciel dowiązania nie są tą samą osobą w globalnie zapisywalnym katalogu z ustawionym bitem sticky:

sysctl -w fs.protected_symlinks=1 root@darkstar:~# cd /tmp/alice_mirror -bash: cd: /tmp/alice_mirror: Permission denied

Twarde dowiązania mogą być nadużywane w podobny sposób jak te symboliczne, ale ich ochrona nie ogranicza się do katalogów zapisywalnych przez wszystkich. jeżeli katalog /etc/ i /home/ znajdują się na tej samej partycji to zwykły użytkownik może utworzyć twarde dowiązanie do /etc/shadow w swoim katalogu domowym:

agresor@darkstar:~$ ln /etc/shadow shadow agresor@darkstar:~$ ls -al | grep shadow -rw-r----- 2 root shadow 1057 Nov 7 20:20 shadow

Jak widzimy plik zachowuje przez cały czas pierwotnego właściciela i uprawnienia, ale mimo to uprzywilejowane programy, które były bezpieczne dla dowiązań symbolicznych, mogą omyłkowo uzyskać dostęp do pliku za pośrednictwem takiego twardego dowiązania. W dodatku możliwe jest przeprowadzenie lokalnego ataku odmowy usługi (ang. local Denial of Service) poprzez pominięcie przydziału (ang. quota) dyskowego i wyczerpanie miejsca na dysku wypełniając twardymi dowiązaniami katalog z globalnym zapisem dla wszystkich. Rozwiązaniem jest niedopuszczenie do tworzenia twardych dowiązań do plików, do których dany użytkownik nie byłby w stanie pierwotnie zapisywać danych:

sysctl -w fs.protected_hardlinks=1 agresor@darkstar:~$ ln /etc/shadow shadow ln: failed to create hard link 'shadow' => '/etc/shadow': Operation not permitted

Bardziej bezpieczne ustawienia dla dowiązań działają w Linuksie 3.6 oraz wyższych i prawdopodobnie są już domyślnie włączone w Twoim systemie.

Więcej informacji: Protected FIFOs and regular files, KernelHardening

Idź do oryginalnego materiału