Kilka dni temu Opublikowano informacje o nowej krytycznej luce w zabezpieczeniach który dotyczy środowisk Linux o nazwie „Pack2TheRoot”. Skatalogowano pod numerem CVE-2026-41651.Ta wada dotyczy PackageKit (narzędzia działającego jako warstwa abstrakcji D-Bus, ujednolicającego zarządzanie pakietami w wielu dystrybucjach)
Wspomniano, że orzeczenie Umożliwia każdemu użytkownikowi lokalnemu bez uprawnień instalację lub usuwanie pakietów w sposób dowolny. Wykorzystując tę lukę, atakujący może uzyskać pełny dostęp do roota w zainfekowanym systemie. Konsekwencje są znaczące, biorąc pod uwagę, że problem występuje od wersji 1.0.2, wydanej ponad dwanaście lat temu (w 2014 roku), i dotyczy domyślnych konfiguracji popularnych dystrybucji, takich jak Ubuntu, Debian, Rocky Linux i Fedora.
Pack2TheRoot: Luka w zabezpieczeniach PackageKit umożliwia dostęp administratora w systemie Linux
El Odkrycie Pack2TheRoot było wynikiem śledztwa pod przewodnictwem Czerwonego Zespołu Deutsche Telekom, który Wykorzystali model sztucznej inteligencji Claude’a Opusa aby pokierować analizą wektorów eskalacji lokalnych uprawnień.
LoNaukowcy początkowo zauważyli, że polecenie pkcon install można wykonać bez konieczności podawania hasła.w niektórych konfiguracjach Fedory, co wzbudziło podejrzenia co do podstawowej autoryzacji. Po potwierdzeniu i odpowiedzialnym zgłoszeniu luki w zabezpieczeniach opiekunom PackageKit, Opracowano działający exploit, choć szczegółowa publikacja została strategicznie opóźniona, aby umożliwić użytkownikom i administratorom zastosowanie niezbędnych aktualizacji.
Mechanika ataku
Korzeń Wrażliwość leży w stanie kariery (Typ TOCTOU: Czas sprawdzenia do czasu użycia) w ciągu zarządzanie transakcjami procesów w tle (daemon) PackageKitPackageKit, działając jako użytkownik root, deleguje autoryzację do systemu polkit. Gdy klient żąda instalacji pakietu, na przykład za pomocą metody InstallFiles, przesyła zestaw flag, które określają zachowanie transakcji.
Konkretne flagi, takie jak SIMULATE lub ONLY_DOWNLOAD, nakazują PackageKit pominięcie autoryzacji polkit. ponieważ stanowią one bezpieczne operacje, które teoretycznie nie zmieniają stanu systemu. Błąd jest wywoływany, ponieważ program obsługi transakcji nadpisuje Wskaźniki te są bezwarunkowo buforowane przy każdym nowym wywołaniu, bez sprawdzania, czy transakcja została już autoryzowana lub jest w trakcie wykonywania.
Un Atakujący może zainicjować transakcję, korzystając ze wskaźników „bezpiecznych” (w ten sposób obchodząc autoryzację polkit) i milisekundy później wyślij drugie żądanie D-Bus dla tej samej transakcji, ale tym razem ze złośliwymi flagami, które nakazują rzeczywistą instalację. Ze względu na architekturę priorytetów pętli zdarzeń GLib (gdzie komunikaty D-Bus są przetwarzane przed bezczynnymi wywołaniami zwrotnymi), drugie żądanie nadpisuje parametry tuż przed rozpoczęciem operacji przez harmonogram.
W rezultacie transakcja wcześniej autoryzowana jako „bezpieczna” zostaje wykonana z podstawionymi parametrami., instalując pakiet z uprawnieniami administratora.
Rozwiązania i łagodzenie
Należy zaznaczyć, że Luka została załatana w PackageKit w wersji 1.3.5W związku z tym twórcy oprogramowania apelują do administratorów systemów, aby sprawdzili, czy ich systemy są podatne na ataki, sprawdzając stan usług za pomocą poleceń, takich jak systemctl status packagekit, lub monitorując aktywność za pomocą pkmon.
Te Główne dystrybucje, m.in. Debian, Ubuntu i Fedora, już rozpoczęły dystrybucję pakietów. Aktualizacje są udostępniane za pośrednictwem oficjalnych kanałów. W przypadku systemów, w których poprawka nie jest natychmiast dostępna, badacze zaproponowali obejście: wdrożenie niestandardowej reguły polkit.
To Reguła natychmiast i bezgłośnie blokuje działania instalacyjne PackageKit. Dla każdego użytkownika innego niż root zapobiega to otwarciu okna wyścigu. Należy pamiętać, że chociaż exploit jest szybki i cichy, pozostawia wyraźny ślad w logach systemowych: po udanym ataku demon PackageKit ulega awarii z powodu błędu asercji (assertion failed: (!transaction->priv->emitted_finished)). Chociaż systemd restartuje usługę, zapobiegając atakowi typu „odmowa usługi”, obecność tego komunikatu w dzienniku zdarzeń (journalctl) jest silnym sygnałem, że system został naruszony.
Na koniec, jeśli jesteś zainteresowany dowiedzeniem się więcej na ten temat, możesz zapoznać się z szczegóły w poniższym linku.