W narzędziu , służące do organizowania wykonywania poleceń w imieniu innych użytkowników, (), co pozwala na wykonywanie poleceń z uprawnieniami roota, jeśli w ustawieniach sudoers istnieją reguły, w których w sekcji sprawdzania identyfikatora użytkownika po słowie kluczowym zezwalającym „ALL” znajduje się wyraźny zakaz uruchamiania z uprawnieniami root („... (ALL, !root)…” ). Luka nie występuje w domyślnych konfiguracjach w dystrybucjach.
Jeśli sudoers ma ważne, ale niezwykle rzadkie w praktyce reguły, które pozwalają na wykonanie określonego polecenia pod UID dowolnego użytkownika innego niż root, osoba atakująca mająca uprawnienia do wykonania tego polecenia może ominąć ustalone ograniczenia i wykonać polecenie z prawa roota. Aby ominąć ograniczenie, wystarczy spróbować wykonać polecenie określone w ustawieniach z UID „-1” lub „4294967295”, co doprowadzi do jego wykonania z UID 0.
Przykładowo, jeśli w ustawieniach jest reguła dająca dowolnemu użytkownikowi prawo do uruchomienia programu /usr/bin/id pod dowolnym UID:
mójhost ALL = (ALL, !root) /usr/bin/id
lub opcja umożliwiająca wykonanie tylko dla konkretnego boba użytkownika:
mójhost bob = (ALL, !root) /usr/bin/id
Użytkownik może wykonać polecenie „sudo -u '#-1' id”, a narzędzie /usr/bin/id zostanie uruchomione jako root, pomimo wyraźnego zakazu w ustawieniach. Problem wynika z przeoczenia wartości specjalnych „-1” lub „4294967295”, które nie prowadzą do zmiany UID, ale ponieważ samo Sudo działa już jako root, bez zmiany UID, polecenie docelowe jest również uruchamiany z prawami roota.
W dystrybucjach SUSE i openSUSE, bez określenia w regule „NOPASSWD”, występuje luka , ponieważ w sudoers domyślnie włączony jest tryb „Defaults targetpw”, który sprawdza UID w bazie danych haseł i wyświetla monit o wprowadzenie hasła użytkownika docelowego. W przypadku takich systemów atak można przeprowadzić tylko wtedy, gdy istnieją reguły w postaci:
mójhost ALL = (ALL, !root) NOPASSWD: /usr/bin/id
Problem rozwiązany w wydaniu . Poprawka jest również dostępna w formularzu . W pakietach dystrybucyjnych luka została już naprawiona , , , , и . W chwili pisania tego tekstu problem pozostaje nierozwiązany и . Luka została zidentyfikowana przez badaczy bezpieczeństwa z Apple.
Źródło: opennet.ru