K

olejny łańcuch prowadzący do lokalnej eskalacji uprawnień został odkryty jądrze Linux. Za pomocą błędów w podsystemach sieciowych ESP (IPsec) (CVE-2026-43284) oraz RxRPC (CVE-2026-43500) umożliwia lokalnemu użytkownikowi uzyskanie uprawnień administratora. Dirty Frag należy do tej samej klasy błędów, co słynne Dirty Pipe i Copy Fail. Głównym problemem nadal pozostaje niewłaściwa obsługa stron pamięci podręcznej (ang. page cache). W normalnych warunkach system operacyjny powinien dbać o to, aby dane modyfikowane przez jądro były odizolowane od plików tylko do odczytu. Jednak w przypadku Dirty Frag mechanizmy szybkiej deszyfracji w modułach esp4, esp6 oraz rxrpc deszyfrują dane bezpośrednio do fragmentów pamięci, które nie należą wyłącznie do jądra systemu. Dzięki temu atakujący można nadpisać w pamięci RAM fragmenty dowolnych plików systemowych (np. /etc/passwd lub programy z bitem SUID, jak /usr/bin/su.

Można powiedzieć, że jest to następca Copy Fail – tutaj też w przeciwieństwie do wielu innych błędów typu LPE atak jest przewidywalny i ma bardzo wysoką skuteczność. Atakujący też używa wywołania systemowego splice() do zmapowania pamięci podręcznej pliku systemowego do potoku (ang. pipe), a następnie wymusza na jądrze zapisanie danych w to samo miejsce. Wygląda to mniej więcej tak:

• Atakujący otwiera plik systemowy (np. /etc/passwd) do odczytu i używa wywołania systemowego splice(). Powoduje to, że strony pamięci podręcznej tego pliku zostają podpięte pod bufor potoku. W tym momencie potok nie zawiera kopii danych, ale bezpośrednio „wskazuje” na fizyczną pamięć, w której system przechowuje treść pliku.
• Kolejnym krokiem jest wykorzystanie protokołów sieciowych jądra, takich jak ESP (ang. Encapsulating Security Payload) lub RxRPC, aby wysłać specjalnie sformatowany pakiet sieciowy, który wymaga od jądra systemu procesu „złożenia” lub „odszyfrowania”.
• Podczas odszyfrowywania lub weryfikacji pakietu, jądro wykonuje operację zapisu, która kopiuje dane z pakietu sieciowego bezpośrednio do bufora potoku przygotowanego w kroku pierwszym. System jednak nie tworzy prywatnej kopii danych przed ich modyfikacją, lecz operuje bezpośrednio na oryginalnej stronie pamięci podręcznej. Ponieważ bufor wskazuje na pamięć podręczną pliku systemowego, jądro nieświadomie nadpisuje treść pliku w pamięci RAM.

System operacyjny „myśli”, że to tylko tymczasowe dane w potoku, podczas gdy w rzeczywistości modyfikowany jest chroniony plik systemowy. Każdy kolejny proces odczytujący ten plik zobaczy już zmodyfikowaną wersję. Pokazuje to, jak mogą być złożone interakcje między optymalizacją wydajności, a zarządzaniem pamięcią w jądrze systemu. Dlaczego ten łańcuch podatności wykorzystuje dwa moduły? Ponieważ przy wykorzystaniu ESP są wymagane uprawnienia do tworzenia przestrzeni nazw użytkownika (unshare), co na niektórych systemach może być zablokowane. Wariant z RxRPC nie wymaga takich uprawnień, więc działa tam, gdzie wariant ESP zawodzi. Z kolei jeśli w systemie brakuje modułu RxRPC, atakujący próbuje wykorzystać wariant ESP. W ten sposób oba warianty wzajemnie uzupełniają swoje słabe strony. Do czasu wypuszczenia poprawionych wersji modułów w jądrach systemowych mitygacją pozostaje zablokowanie ładowania wadliwych modułów na podatnych systemach:

sh -c \
"printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' \
 > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"

Należy mieć jednak na uwadze, że spowoduje to błędy w działaniu połączeń VPN/IPsec opartych na tym standardzie oraz straceniu dostępu do rozproszonego systemu plików AFS, który bazuje na RxRPC.

Więcej informacji: Dirty Frag Write Up, Copy Fail 2: Electric Boogaloo, Dirty Frag: Linux Kernel Local Privilege Escalation via ESP and RxRPC

K

orzystając z protokołu NTP (ang. Network Time Protocol) możemy mieć pewność, że nasze serwery synchronizują swój czas z wyspecjalizowanymi serwerami czasu opartymi na zegarach atomowych (w zależności od poziomu stratum). Utrzymanie precyzyjnego i aktualnego czasu na serwerach (i ogólnie urządzeniach biorących udział w komunikacji) nie jest tylko kwestią możliwości odpowiedzi na pytanie: „- która godzina?”. Poprawny czas na różnego rodzaju urządzeniach to krytyczny element stabilności, bezpieczeństwa i spójności danych. Jeśli zegar serwera znacząco odbiega od rzeczywistości to wiele usług używających czasu w swoich mechanizmach może zacząć działać niepoprawnie. Na przykład duże różnice w postaci dni, miesięcy i lat mogą powodować uznawanie certyfikatów SSL/TLS za nieważne (wydane w przeszłości lub przyszłości). Mniejsze różnice mieszczące się w oknie od 2 do 5 minut mogą powodować problemy z kodami uwierzytelniającymi dla OTP, 2FA, czy Kerberos – bo różnica czasu między klientem, a serwerem spowoduje ich odrzucenie.
[ czytaj całość… ]

Z

apper to mały program, który za pomocą ptrace() manipuluje stosem wektora pomocniczego (ang. auxiliary vector) formatu ELF (ang. Executable and Linkable Format), który posiada format tablicy w postaci par: „klucz – wartość” i jest przekazywany z jądra systemu do procesu w przestrzeni użytkownika, gdy program jest uruchamiany za pomocą funkcji systemowej execve(). Celem wspomnianego wektora (nazywanego również tablicą pomocniczą) jest dostarczenie programowi dodatkowych informacji konfiguracyjnych i środowiskowych, które są niezbędne lub przydatne dla programu w trakcie jego działania (np. jak argumenty linii poleceń czy zmienne środowiskowe – argc, argv, envp).
[ czytaj całość… ]

R

óżne formaty binarne (ang. Miscellaneous Binary Format) to mechanizm jądra Linuksa, który umożliwia systemowi rozpoznawanie i uruchamianie dowolnych formatów plików wykonywalnych za pomocą określonych programów w przestrzeni użytkownika, takich jak: interpretery, emulatory lub maszyny wirtualne. Głównym celem BINFMT_MISC jest rozszerzenie zdolności jądra do interpretowania, jak należy uruchomić dany plik, który nie jest natywnym formatem ELF (ang. Executable and Linkable Format) Linuksa. Użytkownik (z uprawnieniami administratora) może zarejestrować nowy format binarny w określonej ścieżce wirtualnego systemu plików procfs. Rejestracja polega na zdefiniowaniu kryteriów dopasowania plików, które mogą opierać się na: magicznych bajtach (ang. magic bytes) – sekwencji bajtów na początku pliku, które są charakterystyczne dla danego formatu; rozszerzeniu nazwy pliku – na przykład: .py, .sh, .pl itd. W ten sposób użytkownik może po prostu wpisać nazwę pliku, np. skrypt.py, a jądro automatycznie rozpozna jego format i przekaże go do odpowiedniego interpretera, tak jakby był natywnym plikiem wykonywalnym Linuksa (a skrypt nie musi nawet posiadać wewnątrz siebie definicji shebang).
[ czytaj całość… ]

S

hebang (ang. shebang line, bang path) (#!) na początku skryptu jest wymagany, ponieważ informuje jądro systemu operacyjnego (ang. kernel), jakiego interpretara należy użyć do wykonania danego pliku. Gry próbujemy uruchomić plik bezpośrednio (np. ./skrypt.sh), jądro sprawdza pierwsze bajty pliku. Jeśli znajdzie tam sekwencję #!, trakuje resztę linii jako ścieżkę do programu (interpretera), który ma zostać uruchomiony, przekazując mu nazwę skryptu jako argument. Historycznie to powłoka systemowa zajmowała się uruchamianiem skryptów, dopóki nie zostało to zmienione na jądro systemu przez Dennisa Ritche w 1980 roku. Kluczowy jest fakt, że jądro systemu nie przeszukuje zmiennej środowiskowej $PATH podczas obsługi shebang:

agresor@darkstar:~$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

Zmienna $PATH jest używana przez powłokę (np. bash / dash), gdy wpisujemy dane polecenie (np. ls ), aby znaleźć odpowiedni plik wykonywalny. Uruchamiając polecenie śledzące konkretne wywołanie systemowe np. strace możemy zobaczyć jak wykonywane jest polecenie:

root@darkstar:~# strace -e execve cat /etc/hostname
execve("/usr/bin/cat", ["cat", "/etc/hostname"], 0x7ffdae655db8 /* 15 vars */) = 0
darkstar
+++ exited with 0 +++

Jądro systemu ma już pełną ścieżkę (/usr/bin/cat). Z kolei jeśli spojrzymy na kod źródłowy powłoki dash to w pliku exec.c znajdziemy informację o przeszukiwaniu zmiennej $PATH:

/*
 * Do a path search.  The variable path (passed by reference) should be
 * set to the start of the path before the first call; padvance will update
 * this value as it proceeds.  Successive calls to padvance will return
 * the possible path expansions in sequence.  If an option (indicated by
 * a percent sign) appears in the path entry then the global variable
 * pathopt will be set to point to it; otherwise pathopt will be set to
 * NULL.
 *
 * If magic is 0 then pathopt recognition will be disabled.  If magic is
 * 1 we shall recognise %builtin/%func.  Otherwise we shall accept any
 * pathopt.
 */

const char *pathopt;

int padvance_magic(const char **path, const char *name, int magic)

Dlatego jądro systemu, które aktualnie jako pierwsze obsługuje próbę uruchomienia pliku, działa na niższym poziomie i wymaga dokładnej, bezwzględnej (absolutnej) ścieżki do pliku wykonywalnego interpretera (np. /bin/bash, /usr/bin/python3). On, czyli interpreter dalej zajmuje się znalezieniem odpowiedniej ścieżki do programu. Gdybyśmy podali tylko #!bash jako shebang, jądro nie wiedziałoby, gdzie szukać pliku bash (czy jest w /bin, /usr/bin, /usr/local/bin, czy jeszcze gdzieś indziej). W wielu przypadkach możemy także zobaczyć shebang w formie:

#!/usr/bin/env bash

Tutaj pełną ścieżką jest /usr/bin/env. Program env również przeszukuje zmienną $PATH, aby znaleźć pierwszy argument, który mu podano (w tym przypadku: bash). Następnie env uruchamia znaleziony interpreter bash, przekazując mu resztę skryptu. Użycie programu env sprawia również, że skrypt jest bardziej przenośny między różnymi systemami (np. Linux, Unix), na których interpreter bash (lub python itp.) może znajdować się w różnych katalogach, ale program env jest prawie zawsze dostępny pod standardową ścieżką /usr/bin/env.

Więcej informacji: Shebang, env, PATH isn’t real on Linux

I

o_uring jest stosunkowo nowym (wprowadzonym w marcu 2019 roku do jądra 5.1), wysoce wydajnym interfejsem do asynchronicznych operacji wejścia / wyjścia (I/O). Stał się odpowiedzią na brak dobrej i łatwej obsługi wielu jednoczesnych operacji I/O w systemie Linux. Jego zaletą jest możliwość pominięcia „kosztownych” wywołań systemowych (ang. syscalls). Zamiast tradycyjnego modelu, w którym aplikacja musi ciągle „pytać” jądro systemu o status swoich operacji (np. odczyt pliku) io_uring używa dwóch współdzielonych buforów pierścieniowych (stąd jego nazwa). Pierwszy z nich: Submission Queue (SQ) – to kolejka, do której aplikacja wrzuca zadania do wykonania przez jądro. Druga: Completion Queue (CQ) – to kolejna, w której jądro umieszcza wyniki zakończonych zadań. Dzięki temu aplikacja może wysłać całą serię zadań naraz i zostać poinformowana o ich zakończeniu, minimalizując kosztowne przełączanie kontekstu między trybem użytkownika (ang. user space), a trybem jądra (ang. kernel space).
[ czytaj całość… ]

W

systemie Linux wszystko jest plikiem. W celu uruchomienia programu w tym systemie musi on istnieć jako plik i być dostępny w jakiś sposób przez hierarchię systemu plików (tak właśnie działa execve() wykonując program, do którego odnosi się ścieżka dostępu). Plik ten może znajdować się na dysku lub w pamięci (tmpfs), ale nadal potrzebujemy ścieżki do pliku. Dzięki temu bardzo łatwo jest kontrolować, co jest uruchamiane w systemie Linux i ułatwia to wykrywanie zagrożeń oraz narzędzi atakujących. Pomaga to też w nakładaniu opowiednich praw dostępu i polityk kontroli dostępu zapobiegając nieuprzywilejowanym użytkownikom umieszczać i wykonywać pliki gdziekolwiek. Jednak technika użyta w DDexec nie uruchamia nowego procesu w danej ścieżce, ale przejmuje już istniejący.
[ czytaj całość… ]

P

odczas konferencji BSides w Monachium Stephan Berger oraz Asger Strunk przedstawili prelekcję pt. „/proc Dla Analityków Bezpieczeństwa: Ujawnianie Ukrytych Zagrożeń i Skarbów dla Informatyki Śledczej” (ang. „/proc For Security Analysts: Unveiling Hidden Threats And Forensic Treasures”), której agenda oraz poruszane tematy idealnie pasują, aby przeprowadzić małe podsumowanie tego zestawu tematów na przykładach poruszanych w szerszym zakresie na łamach NF.sec. Dlatego pozwolę sobie na małą transkrypcję owej prelekcji wraz z odsyłaniem do bardziej obszernych publikacji zagłębiających się w poruszane tematy. Oprócz dobrze już nam znanych zagadnień autorzy dodali również klika nowych smaczków, z których możemy dowiedzieć się nowych rzeczy i uzupełnić swój warsztat.
[ czytaj całość… ]

P

rzesiąkanie płynu z małych naczyń krwionośnych do otaczających tkanek wymaga natychmiastowego leczenia, aby zapobiec spadkowi ciśnienia krwi i innym poważnym powikłaniom. Identycznie jest w przypadku zespołu podatności o nazwie Leaky Vessels, które wykryto w środowisku wykonawczym kontenerów, w szczególności runC (CVE-2024-21626) oraz w BuildKit (CVE-2024-23651, CVE-2024-23652 i CVE-2024-23653) używanym przez takie projekty jak: Docker, Kubernetes i inne platformy konteneryzacji. Luki te umożliwiają ucieczkę z kontenera, a osobie atakującej, która posiada dostęp do takiego kontenera, wykonanie dowolnego kodu na maszynie hosta, narażając w ten sposób cały system.
[ czytaj całość… ]

B

adacze z SEC Consult, a dokładniej Timo Longin – znany ze swoich ataków na protokół DNS opisał informację o nowej technice ataku o nazwie SMTP Smuggling, która może umożliwiać wysyłanie fałszywych wiadomości e-mail z pominięciem mechanizmów uwierzytelniania. Technika ta wykorzystuje protokół SMTP (ang, Simple Mail Transfer Protocol), w którym atakujący może wykorzystać różnice w sposobie, w jaki wychodzące i przychodzące serwery SMTP interpretują sekwencję wskazującą koniec danych w wiadomości e-mail. Co ciekawe bardzo podobną technikę o nazwie MX Injection opisał Vicente Aquilera Diaz w 2006 roku. Mimo, że jest to znany, długotrwały i dobrze udokumentowany problem, kilka powszechnie używanych serwisów i serwerów świadczących usługi e-mail okazało się podatnych na przeprowadzenie tego ataku.
[ czytaj całość… ]