Bezpieczny linux - cz.1

Bezpieczny linux - cz.1 - Openwall
Autorem projektu jest Alexander Peslyak znany bardziej jako Solar Designer, jest on twórc
m.in. narz dzia John the Ripper, które umo$liwia %amanie hase% oraz dystrybucji Linuxa Owl.
Jednak my zainteresujemy si jego innym dzie%em a mianowicie %atce zwi kszaj cej
bezpiecze(stwo j dra systemu Linux o nazwie Openwall
Na dzie( dzisiejszy wydawane s wersje dla j der serii 2.0, 2.2 oraz 2.4. Z wypowiedzi autora
wynika, $e przenoszenie mechanizmów do nowego b dzie mia%o sens (najwcze/niej) dopiero
po pojawieniu si wersji 2.6.20 (czyli ju$ wkrótce). Mechanizmy ochronne jakie oferuje nam
Openwall:
+ nie wykonywalny stos (non-executable user stack area)
zatrzymuje wi kszo/5 exploitów opartych na przepe%nie( bufora (ang. buffer overflow), które
oparte jest na kasowaniu przez nowy zapis adresu powrotnego funkcji na stosie, by wskaza5
do jakiego/ arbitralnego kodu, który te$ jest po%o$ony na stosie. Je/li obszar stosu jest
chroniony i posiada flag non-execute, podatno/ci j dra na wylew buforu staje si du$o
mniejsza.
Nie wykonywalny stos jest podatny tak$e na atak znany jako powrót do biblioteki libc (ang.
return to libc). Polega on na utworzeniu na stosie poprawnego wywo%ania wspó%dzielonej
funkcji najcz /ciej system() z parametrem /bin/sh. W rezultacie w%amywacz przekazuje
sterowanie do wskazanej funkcji, która uruchamia pow%ok systemow lub wykonuje inne
operacje.
Openwall chroni nas przed atakiem powrotu do libc przez randomizacj adresów funkcji
bibliotek dzielonych. Teraz atakuj cy nie zna ju$ adresy funkcji system() poniewa$
poszczególne segmenty pami ci i adresy funkcji dzielonych s u%o$one inaczej przy ka$dym
uruchomieniu programu.
+ restrykcje dowi za w /tmp (restricted links in /tmp)
opcja wprowadza dodatkowe zabezpieczenia katalogów z atrybutem +t (sticky bit). Pliki w
takich katalogach mog tworzy5 wszyscy u$ytkownicy, lecz ka$dy mo$e modyfikowa5 i
kasowa5 tylko te pliki, których jest w%a/cicielem. Typowym katalogiem tego typu jest /tmp.
Opisywana opcja nie pozwala na tworzenie w takich katalogach twardych dowi za( do
plików, do których nie ma si uprawnie(. U$ytkownik i tak nie móg%by pó=niej skasowa5
takich dowi za(. Istniej ataki polegaj ce na stworzeniu w katalogu /tmp dowi zania do pliku
istotnego z punktu widzenia bezpiecze(stwa (np. /etc/passwd) i nadaniu mu odpowiedniej
nazwy. Przewiduj c nazw pliku tymczasowego tworzonego przez proces z SUID-em,
w%amywacz jest w stanie spowodowa5 nadpisanie pliku, na który wskazuje takie dowi zanie.
+ restrykcje kolejek FIFO w /tmp (restricted FIFOs in /tmp)
opcja wprowadza dodatkowe restrykcje dotycz ce kolejek FIFO w katalogach z atrybutem +t.
Po jej zaznaczeniu u$ytkownik b dzie móg% zapisywa5 dane tylko do tych kolejek, których
jest w%a/cicielem.
+ restrykcje dla /proc (restricted /proc)
ograniczenie dost pu do systemu plików /proc. Po zaznaczeniu tej opcji, u$ytkownicy inni ni$
root b d mogli zobaczy5 jedynie list w%asnych procesów. Nie b d mie5 tak$e dost pu do
listy po% cze( sieciowych (netstat). Dodatkowo opcja ta uniemo$liwia korzystanie z polecenia
dmesg.
+ wymuszenie sprawdzenia liczby limitu procesów dla execve() (enforce
RLIMIT_NPROC on execve(2))
j dro umo$liwia ustalenie limitu ilo/ci procesów dla u$ytkownika poprzez wywo%anie funkcji
setrlimit(). Niestety limit ten jest sprawdzany tylko podczas wywo%ywania przez procesy
funkcji fork(). Je/li proces zmieni swój UID, mo$liwe jest przekroczenie ustalonego
wcze/niej limitu. Nie stanowi to du$ego zagro$enia, poniewa$ UID mog zmienia5 tylko
procesy uprzywilejowane, ale ma to znaczenie w przypadku programów SUID/SGID, które
po wykonaniu uprzywilejowanych operacji zmieniaj swój UID na UID u$ytkownika.
Funkcja fork() jest w nich zazwyczaj wywo%ywana przed zmian UID, co pozwala na
omini cie ograniczenia. Zaznaczenie tej opcji zapobiega takim sytuacjom.
+ niszczenie nieu0ywanych obszarów pami2ci dzielonej (destroy shared memory
segments not in use)
opcja pozwala na ustalenie limitu pami ci wykorzystywanej przez jeden proces, ale segmenty
pami ci dzielonej mog istnie5 bez przypisanego procesu, co nie zalicza ich do tego limitu.
Po w% czeniu tej opcji, j dro b dzie usuwa%o segmenty pami ci dzielonej, gdy korzystaj ce z
nich procesy zako(cz dzia%anie. Zabezpieczy to system przed mo$liwo/ci zape%nienia ca%ej
wolnej pami ci Uwaga !Aby korzysta5 z niektórych funkcji Openwalla w po% czeniu z
niektórymi wersjami biblioteki glibc oraz programów z pakietów procps lub psmisc, mo$e
by5 koniczne ich zaktualizowanie. Odpowiednie patche znajdziemy w katalogu optional po
rozpakowaniu Openwalla. Dodatkowo znajdziemy tam do% czone dwa programy:
chstk
umo$liwia wskazanie programów uprawnionych do wykonywania kodu na stosie. Ustawia on
flag w nag%ówku pliku ELF, a podczas tworzenia nowego procesu system sprawdza
obecno/5 flagi i nadaje jej odpowiednie uprawnienia
stacktest
umo$liwia przetestowanie naszego systemu czy jest podatny na ataki przepe%nienia buforu
(umo$liwia sprawdzenia tak$e naszego kompilatora gcc). W standardowej instalacji
Slackware wszystkie ataki s mo$liwe Kompilacja obu programów przy pomocy gcc:
•
•
# gcc chstk.c –o chstk
# gcc stacktest.c –o stacktest
Przyk6adowa konfiguracja 6atki dla systemu Linux Slackware dla kernela w wersji
2.4.34
1. Jako u$ytkownik root nadajemy katalogowi /usr/src prawo dost pu tylko dla roota nie
$yczymy sobie przecie$ aby jakikolwiek user podgl da% nasza konfiguracje j dra (domy/lnie
ma prawo dost pu do /usr/src) a wi c wydajemy nast puj ca komend :
•
•
# chmod 700 /usr/src
# cd /usr/src
2. Pobieramy =ród%a kernela
•
•
•
•
# wget http://www.kernel.org/pub/linux/kernel/v2.4/linux-2.4.34.tar.gz
# tar zxf linux-2.4.34.tar.gz { rozpakowujemy }
# ln -s linux-2.4.34 linux { tworzymy dowi zanie }
# cd linux
3. Pobieramy patch Openwalla dla odpowiedniej wersji kernela
•
•
# wget http://www.openwall.com/linux/linux-2.4.34-ow1.tar.gz
# tar zxf linux-2.4.33-ow1.tar.gz
Instalujemy %atk :
•
# patch -p1 < linux-2.4.34-ow1/linux-2.4.34-ow1.diff
Teraz mo$emy rozpocz 5 kompilacj kernela, mamy do wyboru kilka trybów
umo$liwiaj cych konfiguracj :
Tekstowy: meke config
b dziemy kolejno pytani o uruchamianie funkcji kernela i za% czanie ich na sta%e lub jako
modu%
Konsolowy: make menuconfig
chyba najbardziej popularna metoda konfiguracji wykorzystuj ca bibliotek ncurses
Graficzny: make xconfig
wykorzystuj cy bibliotek qt, dla kde make gconfig – wykorzystuj cy bibliotek gtk, dla
gnome.
Uruchamiamy konfiguracj konsolow : # make menuconfig
Po skonfigurowaniu w%a/ciwym parametrów naszego jajka mo$emy przej/5 do Security
options gdzie znajdziemy wcze/niej opisane opcje.
W przypadku, gdy stosujemy %atk na serwerze, z którego korzysta wielu u$ytkowników,
zaleca si zaznaczenie wszystkich opcji.
Je/li chcemy zabezpieczy5 stacj robocz , u$ywan tylko przez zaufane osoby, wystarczy, $e
w% czymy jedynie non-executable user stack area. Opcja ta zabezpieczy nas przed
ewentualnymi próbami wykonania kodu exploita dla programu przyjmuj cego po% czenia z
zewn trz. Pozosta%e zabezpieczenia chroni przed atakami lokalnymi, które na stacji roboczej
raczej nie b d mie5 miejsca. W ten sposób na pewno nie stracimy kompatybilno/ci z
u$ywanymi programami i nie nast pi odczuwalne zmiany w dzia%aniu systemu.
Zapisujemy konfiguracj i przyst pujemy do kompilacji j dra.
•
•
•
•
•
•
•
•
•
•
•
# make dep { tworzy wszystkie powi zania }
# make clean { usuwamy zb dne /mieci z kodu }
# make bzImage { kompilujemy obraz }
Po skompilowaniu nasz obraz znajduje si w katalogu
/usr/src/linux/arch/i386/boot/bzImage przekopiujemy go do /boot i nadamy
odpowiedni nazw
# cp /usr/src/linux/arch/i386/boot/bzImage /boot/linux-2.4.34-ow
# make module { kompilujemy modu%y }
# make modules_install { kopiuje modu%y do /lib/module/<nazwa_jajka>
# cp /usr/linux/System.map /boot/System.map-2.4.34-ow { mapa systemowa }
# cd /boot
# rm System.map { kasujemy stara map }
# ln –s System.map-2.4.34-ow System.map
Kolejny krok to konfiguracja lilo, w pliku /etc/lilo.conf dodamy nast puj ce wpisy
•
•
•
•
image = /boot/linux-2.4.34-ow
root = /dev/hda1
label = linux-owl
read-only
nast pnie aby konfiguracja by%a uaktywniona nale$y prze%adowa5 lilo
# lilo
Uwaga ! Teraz pozostaje edycja pliku /etc/fstab w celu wskazania uprzywilejowanego
u$ytkownika (za wyj tkiem roota) którego nie b d dotyczy5 restrykcje /proc. W tym celu
dodamy nowego u$ytkownika i przypiszemy go do grupy o tej samej nazwie.
•
•
# groupadd proc
# useradd –g proc proc
W pliku /etc/fstab zmieniamy wpis
•
•
•
proc
na
none
/proc
proc
defaults
0 0
/proc
proc
defaults,gid=107
0 0
gdzie 107 to id grupy proc który mo$emy sprawdzi5 komend
# id –g proc
Warto tak$e zmieni5 wpis w /etc/inted.conf
•
•
•
auth
na
auth
stream tcp
wait
root
/usr/sbin/in.identd
in.identd
stream tcp
wait
proc /usr/sbin/in.identd
in.identd
Teraz warto dopiszemy do syslog.conf instrukcje która b dzie logowa5 próby przepe%nienia
bufora i inne dopisujemy
•
kern.alert
/var/log/openwall
a nast pnie:
•
•
•
# touch /var/log/openwall { tworzymy plik }
# chown root.wheel /var/log/openwall { w%a/ciciel root i grupa wheel }
# chmod 640 /var/log/openwall { RW dla w%a/ciciela i R dla grupy }
Uruchamiamy ponownie nasz serwer i przy bootloaderze wybieramy nasze nowe jajko je/li
po testach jeste/my zadowoleni z dzia%ania i nie widzimy $adnych b% dów w pracy systemu
ustawiamy w lilo aby domy/lnie uruchamia% nasze nowe j dro.
# lilo –D linux-2.4.34-ow