Firma Qualys wykry\u0142a dwie podatno\u015bci w narz\u0119dziach apport (CVE-2025-5054) i systemd-coredump (CVE-2025-4598), kt\u00f3re s\u0105 u\u017cywane do przetwarzania zrzut\u00f3w pami\u0119ci, generowanych po awaryjnym zako\u0144czeniu proces\u00f3w. Podatno\u015bci te umo\u017cliwiaj\u0105 uzyskanie dost\u0119pu do zrzut\u00f3w pami\u0119ci, przechowywanych po awaryjnym zako\u0144czeniu aplikacji suid lub niekt\u00f3rych systemowych proces\u00f3w w tle, w kt\u00f3rych pami\u0119ci mog\u0105 znajdowa\u0107 si\u0119 zbuforowane dane logowania lub klucze szyfrowania. Narz\u0119dzie apport jest automatycznie wywo\u0142ywane w celu zapisania zrzut\u00f3w pami\u0119ci w Ubuntu, a systemd-coredump w Red Hat Enterprise Linux 9+, Fedora oraz wielu innych dystrybucjach Linuxa. <\/p>\n
Zademonstrowano technik\u0119 ataku, w kt\u00f3rej tworzono warunki do awaryjnego zako\u0144czenia aplikacji suid unix_chkpwd i uzyskania dost\u0119pu do zrzutu pami\u0119ci ze stanem w momencie awarii. W zapisanym zrzucie pami\u0119ci znajdowa\u0142y si\u0119 hasze hase\u0142 u\u017cytkownik\u00f3w systemu, kt\u00f3re pozosta\u0142y w pami\u0119ci awaryjnie zako\u0144czonego procesu po za\u0142adowaniu zawarto\u015bci \/etc\/shadow. Mo\u017cliwo\u015b\u0107 wykorzystania tych podatno\u015bci zademonstrowano w Ubuntu 24.04 oraz Fedora 40\/41, ale przypuszcza si\u0119, \u017ce inne dystrybucje r\u00f3wnie\u017c mog\u0105 by\u0107 nara\u017cone na podobne ataki. <\/p>\n
Obie podatno\u015bci s\u0105 spowodowane stanem wy\u015bcigu, kt\u00f3ry pozwala na zamian\u0119 awaryjnie zako\u0144czonego procesu suid na inny proces w momencie po rozpocz\u0119ciu przetwarzania przez j\u0105dro awarii, ale przed sprawdzeniem przez obs\u0142ug\u0119 w przestrzeni u\u017cytkownika parametr\u00f3w procesu przez \/proc\/pid\/files. Wywo\u0142anie apport i systemd-coredump odbywa si\u0119 w nast\u0119puj\u0105cy spos\u00f3b: j\u0105dro, otrzymuj\u0105c informacj\u0119 o awaryjnym zako\u0144czeniu procesu, wywo\u0142uje obs\u0142ug\u0119, wskazan\u0105 w pliku \/proc\/sys\/kernel\/core_pattern, po czym przekazuje jej zawarto\u015b\u0107 zrzutu pami\u0119ci przez strumie\u0144 wej\u015bciowy. <\/p>\n
Generacja zrzutu pami\u0119ci i uruchomienie obs\u0142ugi nie odbywa si\u0119 natychmiast i tego czasu wystarcza, aby zamieni\u0107 zako\u0144czony proces suid na zwyk\u0142y proces u\u017cytkownika. W przypadku zamiany uruchomiona obs\u0142uga zrzut\u00f3w pami\u0119ci uzna, \u017ce awaria mia\u0142a miejsce nie w procesie suid, ale w zwyk\u0142ej aplikacji u\u017cytkownika i odpowiednio zapisze zrzut pami\u0119ci z mo\u017cliwo\u015bci\u0105 dost\u0119pu zwyk\u0142ego u\u017cytkownika, a nie tylko administratora. <\/p>\n
Atak na apport sk\u0142ada si\u0119 z nast\u0119puj\u0105cych krok\u00f3w: <\/p>\n
Aby uzyska\u0107 dla nowego procesu potrzebny identyfikator, zbie\u017cny z identyfikatorem procesu suid, przed wys\u0142aniem sygna\u0142u SIGSEGV, proces suid jest zatrzymywany sygna\u0142em SIGSTOP, a w czasie zatrzymania cyklicznie uruchamiane s\u0105 nowe procesy, a\u017c zostanie uzyskany PID z poprzednim numerem, bliskim to\u017csamo\u015bci podmienianego procesu suid. Po przemieszczeniu numeracji PID sygna\u0142y SIGSEGV i SIGCONT s\u0105 wysy\u0142ane do procesu suid, po czym wysy\u0142any jest SIGKILL i cyklicznie uruchamiane s\u0105 nowe procesy, aby osi\u0105gn\u0105\u0107 ten sam PID, co proces suid. <\/p>\n
Je\u015bli chodzi o systemd-coredump, z jednej strony przeprowadzenie ataku na niego jest prostsze, poniewa\u017c nie ma potrzeby zast\u0119powania procesu suid procesem w oddzielnej przestrzeni u\u017cytkownika; wystarczy uzyska\u0107 zgodno\u015b\u0107 AT_UID i AT_EUID. Z drugiej strony, systemd-coredump jest napisany w j\u0119zyku C i uruchamia si\u0119 do\u015b\u0107 szybko, co daje mniej czasu na podmian\u0119, w przeciwie\u0144stwie do apport, kt\u00f3ry jest napisany w Pythonie i podczas inicjalizacji \u0142aduje r\u00f3\u017cne pliki .pyc. Podobny problem mo\u017cna rozwi\u0105za\u0107 sztucznym spowolnieniem systemd-coredump \u2014 podczas wywo\u0142ania pliku suid przekazywana jest bardzo du\u017ca liczba argument\u00f3w wiersza polece\u0144, co tworzy potrzebne op\u00f3\u017anienie, kt\u00f3re wyst\u0119puje podczas analizy \/proc\/pid\/cmdline. <\/p>\n
Podczas analizy podatno\u015bci badacze r\u00f3wnie\u017c zauwa\u017cyli, \u017ce systemd-coredump podczas konfigurowania wywo\u0142ania nie okre\u015bla w \/proc\/sys\/kernel\/core_pattern flagi \u201e%d\u201d, co pozwala atakuj\u0105cemu na wywo\u0142anie awaryjnego zako\u0144czenia proces\u00f3w dzia\u0142aj\u0105cych jako root, kt\u00f3re tworz\u0105 inne procesy, zmieniaj\u0105c identyfikator u\u017cytkownika na uprzywilejowanego u\u017cytkownika, pod kt\u00f3rym dokonuje si\u0119 ataku. Taka mo\u017cliwo\u015b\u0107 pozwala na przeprowadzenie ataku nie tylko na aplikacje setuid, ale tak\u017ce na takie procesy jak sshd-session (OpenSSH), sd-pam (systemd) i cron, w celu uzyskania poufnych danych osadzonych w ich pami\u0119ci, takich jak klucze prywatne, hashe hase\u0142 z \/etc\/shadow, oznaczenia kanaryjne ze stosu oraz dane do obej\u015bcia randomizacji przestrzeni adresowej (ASLR). <\/p>\n