C

iekawa podatność pojawiła się w systemd, która bazuje na jednej z ucieczek z programu sudo. Otóż wersje systemd w wersji sprzed 247 umożliwiają eskalację uprawnień poprzez ominięcie ograniczeń uprawnień nakładanych przez konfigurację (/etc/sudoers) programu sudo dla danego użytkownika. Na przykład systemd w podatnych wersjach nie ustawia wartości “1” dla zmiennej LESSSECURE, dlatego program less biorący udział w tym łańcuchu zdarzeń jest w stanie uruchomić inny program (np. powłokę shell) z uprawnieniami administratora systemu. Wystarczy zmusić terminal do przekazania danych wyjściowych polecenia systemctl do programu less, co możemy bardzo prosto osiągnąć poprzez zmniejszenie okna samego terminala.
[ czytaj całość… ]

U

żytkownicy posiadający UID większy od INT_MAX posiadają możliwość wykonania dowolnego polecenia za pomocą systemctl. Błąd nie tkwi w samym systemd, jak mogliśmy się przyzwyczaić, ale w narzędziu pkttyagent, w którym PolicyKit (polkit) podczas wystąpienia błędu twierdzi, że użytkownik jest uprawniony do wykonania polecenia. Przykład działania takiego zachowania:

$ systemctl --version
systemd 239
$ pkttyagent --version
pkttyagent version 0.115
$ id 
uid=4000000000(someuser) gid=100(users) groups=100(users)
$ systemctl stop sshd.service
(pkttyagent:3342): GLib-GObject-WARNING **: 13:28:53.802: value "-294967296" 
of type 'gint' is invalid or out of range for property 'uid' of type 'gint' **
ERROR:pkttyagent.c:156:main: assertion failed: 
(polkit_unix_process_get_uid (POLKIT_UNIX_PROCESS (subject)) >= 0)
$ systemctl is-active sshd.service
inactive

Luka sama w sobie nie jest groźna, ponieważ do stworzenia użytkownika z takim UID są już wymagane prawa administratora. Można ją jednak użyć do zamaskowania użytkownika, który ma podniesione prawa, a nie ma przypisanego UID/GID=0. Do czasu naprawienia luki można użyć obejścia w postaci wyłączenia polkit’a:

systemctl mask polkit && systemctl stop polkit

Więcej informacji: systemd issue, polkit issue, CVE-2018-19788

L

uka została ujawniona podczas zgłoszenia błędu na githubie. systemd nie potrafi obsłużyć odpalenia procesu użytkownika, którego login zaczyna się od liczby np. 0day i tym samym uruchamia proces z prawami administratora zamiast owego użytkownika. Brzmi to dość drastycznie:

> In case of bug report: Expected behaviour you didn’t see
The process started by systemd should be user previlege

> In case of bug report: Unexpected behaviour you saw
The process started by systemd was root previlege

[ czytaj całość… ]

K

rytyczna podatność została odkryta w ulubionym monolicie inita świata linuksowego – systemd. Pozwala ona na potencjalne wywołanie przepełnienia bufora oraz uruchomienie szkodliwego kodu na atakowanej maszynie, a to wszystko za pomocą odpowiedzi DNS. CVE-2017-9445 aktualnie rezyduje w funkcji dns_packet_new komponentu systemd-resolved służącego do obsługi odpowiedzi DNS, który zapewnia rozwiązywanie nazw DNS dla innych daemonów i aplikacji sieciowych. Według oficjalnego ostrzeżenia opublikowanego we wtorek specjalnie spreparowana odpowiedź od wrogiego serwera DNS może spowodować awarię programu ‘systemd-resolved’. Wysłanie bardzo dużej odpowiedzi DNS może doprowadzić do przepełnienia buforu umożliwiając atakującemu nadpisanie pamięci prowadząc do zdalnego wykonania kodu. Oznacza to, że napastnicy mogą zdalnie uruchomić złośliwe oprogramowanie na docelowym serwerze za pośrednictwem wrogiej usługi DNS. Luka ta występuje od wersji 223, która pojawiła się w czerwcu 2015 roku i jest obecna we wszystkich wersjach do 233 wydanej w marcu tego roku. Oczywiście systemd-resolve musi być uruchomiony w systemie, aby stanowił dla niego zagrożenie. Błąd dotyka takie dystrybucje jak: Ubuntu 16.10 oraz 17.04; Debian Stretch (9), Buster (10) i Sid (wersja niestabilna) oraz inne używające systemd.

Zobacz również: systemd v228, screen root exploit i globalne problemy z setuid

Sebastian Krahmer z SUSE Security Team odkrył lokalny exploit w systemd v228. Przez ten błąd użytkownik znajdujący się w podatnym systemie jest w stanie podnieść swoje uprawnienia do roli administratora. Patrząc na sedno błędu z wysokiego poziomu proces ten jest dość prosty:

1) Systemd używa wartości -1 do reprezentacji nieprawidłowej wartości mode_t (praw dostępu do systemu plików)
2) Przez przypadek wartość ta jest przekazywana podczas tworzenia (open) nowego pliku, co w rezultacie dawało nam plik z ustawionymi wszystkimi bitami dostępu: globalny zapis, globalne wykonanie i najgorsze: setuid dla root.
3) Atakujący może nadpisać ten plik dowolnym programem, ponieważ jest dostępny do zapisu dla wszystkich.
4) Atakujący może wykonać ten plik z wgranym programem, ponieważ jest dostępny do wykonania dla wszystkich.
5) Atakujący wykonuje program z prawami administratora, ponieważ plik posiada setuid dla root.
[ czytaj całość… ]