prelink

prelink – program należący do wolnego oprogramowania napisany przez Jakuba Jelínka z firmy Red Hat dla systemów operacyjnych kompatybilnych z POSIX (ze względu na modyfikację plików wykonywalnych ELF). Jego zadaniem jest przyspieszenie systemu poprzez redukcję czasu jakiego potrzebuje program na uruchomienie. Rzeczywiste wyniki mogą się różnić, aczkolwiek wygląda na to, że rozwiązanie to pomaga w środowiskach wykorzystujących wiele bibliotek dynamicznych, takich jak na przykład w środowisku graficznym KDE.

Równoważnym procesem na systemach Mac OS X jest "wstępne wiązanie" (ang. prebinding).

Działanie

Większość programów wymaga bibliotek do funkcjonowania. Biblioteki mogą być jednorazowo włączone do programu przez linker w linkowaniu statycznym lub dołączone do programu w czasie jego działania w procesie dynamicznego linkowania. Pomimo tego, że dynamiczne linkowanie pozwala na oszczędność obsługi, i rozmiaru kodu, przy każdym uruchomieniu programu ponownie wyszukiwane są jego biblioteki. Ze względu na to, że biblioteki mogą zmienić swoje położenie w pamięci spada wydajność, czyli im więcej bibliotek dynamicznych powiązanych z danym programem tym większy spadek. Prelink niweluje ten spadek poprzez wykorzystanie systemowego linkera w odwracalnym procesie linkowania ("prelinkowanie" pliku wykonywalnego) poprzez relokowanie. Następnie wyszukiwanie bibliotek konieczne jest jedynie w przypadku gdy biblioteki uległy zmianie na przykład poprzez aktualizację od momentu ich przelinkowania.

Losowość

Prelink uruchomiony z opcją "-R" losowo wybierze adres z którego biblioteki są ładowane. Czyni to atak na system typu "return-to-libc" trudniejszym, ponieważ adresy z których biblioteki są ładowane są unikalne dla danego systemu. Powodem dla którego Prelink to robi jest dostarczana przez jądro funkcjonalność losowości warstwy przestrzeni adresu (ang. ASLR), biblioteki nie mogą być wykorzystywane w połączeniu z Prelink bez uniemożliwienia głównego celu jego działania, i zmuszenia dynamicznego linkera do przeprowadzania relokacji podczas ładowania programu.

Tak jak zostało to już wyjaśnione Prelink i funkcja losowości adresu biblioteki na proces nie mogą być wykorzystywana razem. Zamiast całkowicie usuwać ową funkcję bezpieczeństwa, Prelink dostarcza swoją własną losowość adresów; jakkolwiek jednak nie pomaga to w wycieku informacji spowodowanym przez Prelink. Atakujący z możliwością odczytu określonych plików na systemie docelowym mogą poznać gdzie biblioteki są ładowane w zastrzeżonych demonach (usługach); często sama biblioteka libc jest wystarczająca, jako że jest to powszechnie najczęściej wykorzystywana biblioteka w atakach typu "return-to-libc".

Poprzez odczyt pliku biblioteki współdzielonej takiej jak libc atakujący z dostępem lokalnym może poznać i wczytać adres biblioteki libc w każdej dostępnej aplikacji na systemie. Jako że większość programów posiada dowiązania do libc, plik biblioteki libc musi być odczytywalny; każdy atakujący z dostępem lokalnym może uzyskać informacje o przestrzeni adresu wyżej uprzywilejowanych procesów. Dostęp lokalny może być powszechnie uzyskany za pomocą kont powłoki lub konta serwerów sieci Web umożliwiających użycie skryptów CGI, które mogą odczytać, i wyświetlić każdy plik znajdujący się w systemie.

Ze względu na to, że Prelink często jest uruchamiany w określonych odstępach czasu - zazwyczaj są to dwa tygodnie - to adres każdej biblioteki ma szansę na zmianę. Zazwyczaj jest także używany w trybie inkrementacji, w którym to już wcześniej prelinkowane biblioteki nie są ponownie uaktualniane, a zatem ich adres także nie ulega zmianie, chyba że jest to wymuszone przez parametr, bądź aktualizację biblioteki.

Jakub Jelínek wskazuje, że pliki wykonywalne niezależne od pozycji (ang. PIE) ignorują proces prelinkowania na dystrybucji Red Hat Enterprise Linux, oraz Fedora Core. Zaleca także by programy sieciowe, i uprzywilejowane (ang. SUID) kompilowane były z PIE w celu osiągnięcia bezpieczniejszego środowiska.

Możliwe niedogodności

Okazjonalnie proces prelinkowania może spowodować problemy przy weryfikowaniu aplikacji, i restartować takie biblioteki jak blcr, jak i inne (np. OpenMPI), które wykorzystują blcr wewnętrznie. Szczególnie gdy weryfikowany jest program na jednym hoście przy próbie restartu na innym, uruchomiony ponownie program może zakończyć się naruszeniem ochrony pamięci, ze względu na różnicę w losowym adresowaniu pamięci specyficznych dla konkretnego hosta.