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.

Podatność została naprawiona już rok temu w niecałe trzy miesiące od momentu przedstawienia i występowała tylko w wersji 228. Dlaczego dopiero teraz luka ta ujrzała światło dzienne? Ponieważ wcześniej została niepoprawnie sklasyfikowana jako DoS (Denial of Service) i zespół odpowiedzialny za rozwój i utrzymanie systemd nie poprosił o CVE-ID. Gdyby tak się stało ktoś mógłby zauważyć, że błąd ten był czymś więcej niż prostym DoS. Sam Krahmer zwraca uwagę na fakt, że commit log jest tak duży, że trudno dostrzec w nim zmiany dotyczące kwestii bezpieczeństwa.

Kopiąc głębiej można dojść do ciekawego odkrycia. Badacz bezpieczeństwa o pseudonimie Halfdog już w 2015 roku ujawnił i zaadresował do rozwiązania lukę w sposobie, w jakim system Linux czyści bity setuid i setgid pliku, gdy następuje do niego zapis. Gdy system po prostu tworzy pusty plik setuid, uzyskanie uprawnień administratora wymaga wykonania zapisu do tego pliku. Problem pojawia się, gdy tylko użytkownik inny niż administrator dokonuje zapisu do takiego pliku. Wówczas bit setuid jest po cichu czyszczony. Można jednak przechytrzyć ten etap i zmusić proces z uprawnieniami administratora, aby sam dokonał zapisu.

Powracając do systemd. Podatność mogła zostać zażegnana jeśli wartość umask zostałaby ustawiona na wartość np. 022 – wówczas plik suid nie pozwalałby na zapis dla wszystkich. Jednakże opiekun systemd – David Strauss odrzucił tą bezpieczną wartość dość dziwnie argumentując swój wybór (warto przypomnieć, że w 2016 systemd umożliwiał zawieszenie systemu “jednym tweetem”).

Systemd nie jest jedynym, który zaliczył ostatnio problem z bitem setuid. Dwa dni temu pojawił się exploit wykorzystujący błąd obecny od listopada 2016 r. w programie screen…

Także zasada, aby wyrzucić jak najwięcej tych bitów z plików w systemie nadal obowiązuje.

Więcej informacji: Thoughts on the Systemd Root Exploit, Dangers of SUID Shell Scripts