W j\u0105drze Linux odkryto pi\u0105t\u0105 (1, 2, 3) krytyczn\u0105 luk\u0119 w ci\u0105gu ostatnich dw\u00f3ch tygodni, kt\u00f3ra pozwala u\u017cytkownikowi na podniesienie swoich uprawnie\u0144 w systemie. Opublikowano dwa dzia\u0142aj\u0105ce exploity: sshkeysign_pwn umo\u017cliwia nieuprzywilejowanemu u\u017cytkownikowi odczytanie zawarto\u015bci prywatnych kluczy SSH hosta w \/etc\/ssh\/ssh_host_*_key, a chage_pwn \u2014 odczytanie zawarto\u015bci pliku \/etc\/shadow z haszami hase\u0142 u\u017cytkownik\u00f3w. <\/p>\n
Informacje o luce nie by\u0142y planowane do ujawnienia, ale jeden z badaczy bezpiecze\u0144stwa na podstawie zaproponowanej poprawki do j\u0105dra by\u0142 w stanie okre\u015bli\u0107 istot\u0119 luki, kt\u00f3ra umo\u017cliwia odczyt plik\u00f3w dost\u0119pnych tylko dla u\u017cytkownika root, na przyk\u0142ad \\\/etc\\\/shadow. W dodanej do j\u0105dra zmianie poprawiana by\u0142a logika stosowania funkcji get_dumpable() w ptrace przy okre\u015blaniu poziomu dost\u0119pu w funkcji ptrace_may_access(). <\/p>\n
Bezpo\u015brednia luka jest spowodowana stanem wy\u015bcigu, prowadz\u0105cym do mo\u017cliwo\u015bci nieuprzywilejowanego dost\u0119pu do deskryptora pliku pidfd po dost\u0119pie do pliku z procesu suid root. W momencie czasu mi\u0119dzy otwarciem pliku a zrzuceniem uprawnie\u0144 w programie suid (na przyk\u0142ad przez funkcj\u0119 setreuid) pojawia si\u0119 sytuacja, w kt\u00f3rej aplikacja uruchamiaj\u0105ca program suid root przez deskryptor pidfd mo\u017ce uzyska\u0107 dost\u0119p do otwartego w programie suid pliku, nawet je\u015bli nie zezwalaj\u0105 na to uprawnienia dost\u0119pu do pliku. <\/p>\n
Okno do wykorzystania pojawia si\u0119, poniewa\u017c funkcja '__ptrace_may_access()' pomija sprawdzenie mo\u017cliwo\u015bci dost\u0119pu do pliku, je\u015bli pole task->mm jest ustawione na warto\u015b\u0107 NULL po wykonaniu exit_mm(), ale przed wywo\u0142aniem exit_files(). W obecnej chwili wywo\u0142anie systemowe pidfd_getfd uwa\u017ca, \u017ce identyfikator u\u017cytkownika (uid) wywo\u0142uj\u0105cego procesu odpowiada identyfikatorowi, kt\u00f3remu zezwolono na dost\u0119p do pliku. Co ciekawe, problem by\u0142 zauwa\u017cany ju\u017c w 2020 roku, ale pozosta\u0142 nierozwi\u0105zany. <\/p>\n
W exploicie, kt\u00f3ry uzyskuje zawarto\u015b\u0107 \\\/etc\\\/shadow, atak sprowadza si\u0119 do cyklicznego uruchamiania przez fork+execl aplikacji \\\/usr\\\/bin\\\/chage z flag\u0105 suid root, odczytuj\u0105cej zawarto\u015b\u0107 \\\/etc\\\/shadow. Po odga\u0142\u0119zieniu procesu wykonane jest wywo\u0142anie systemowe pidfd_open i przeprowadzany jest cykliczny przegl\u0105d dost\u0119pnych deskryptor\u00f3w pidfd przez wywo\u0142anie systemowe pidfd_getfd i ich sprawdzanie przez \\\/proc\\\/self\\\/fd. W exploicie sshkeysign_pwn podobne manipulacje s\u0105 przeprowadzane z programem suid root ssh-keysign. <\/p>\n
CVE identyfikator problemu nie zosta\u0142 jeszcze przypisany, aktualizacja j\u0105dra i pakiet\u00f3w w dystrybucjach nie zosta\u0142a opublikowana. W wydanych kilka godzin temu j\u0105drach 7.0.7, 6.18.30 i 6.12.88 luka nie zosta\u0142a usuni\u0119ta. Na moment pisania wiadomo\u015bci mo\u017cna korzysta\u0107 tylko z \u0142atki. Dyskutowane s\u0105 mo\u017cliwe obej\u015bcia blokowania luki, takie jak ustawienie sysctl kernel.yama.ptrace_scope=3 lub usuni\u0119cie flagi suid root z plik\u00f3w wykonywalnych w systemie (przynajmniej z narz\u0119dzi ssh-keysign i chage, u\u017cywanych w exploitach).