Linus Torvalds włączył do rdzenia dokument regulujący proces obsługi błędów związanych z bezpieczeństwem, określający model zagrożeń, wyjaśniający, jakie błędy w rdzeniu traktowane są jako podatności, oraz omawiający działania w przypadku błędów wykrytych za pomocą AI. Dokument został przygotowany przez Willy'ego Tarreau, autora HAProxy i długoletniego dewelopera jądra Linux, który był odpowiedzialny za wsparcie kilku stabilnych gałęzi rdzenia. Jako podstawę wykorzystano ustalenia osiągnięte w trakcie dyskusji o niedawno odkrytych krytycznych podatnościach w rdzeniu (1, 2, 3, 4), ujawnionych przed publikacją poprawek i dla których dzięki AI udało się od razu stworzyć działające exploity.
Większość błędów związanych z bezpieczeństwem powinna być przetwarzana publicznie, aby przyciągnąć jak najszerszą publiczność i znaleźć optymalne rozwiązanie. Tylko pilne informacje o łatwo eksploatowanych podatnościach, które stanowią zagrożenie dla wielu użytkowników i mogą prowadzić do uzyskania rozszerzonych uprawnień lub możliwości, należy przesyłać do osobnej prywatnej listy mailingowej.
Podatności wykryte przy użyciu asystentów AI należy zawsze omawiać publicznie, ponieważ podobne problemy często odkrywane są równocześnie przez kilku badaczy. Nie należy jednak ujawniać exploitu w raporcie — wystarczy wspomnieć, że jest dostępny, i przekazać go prywatnie w odpowiedzi na prośbę osoby odpowiedzialnej za projekt.
Oddzielnie opisano zasady przesyłania raportów stworzonych za pomocą asystentów AI. Tego typu raportów otrzymuje się bardzo wiele i dzięki nim od czasu do czasu udaje się wykrywać błędy w słabo zrecenzowanych częściach kodu, ale osoby odpowiedzialne często je ignorują z powodu niskiej jakości i niedokładności. Podstawowe wymagania dotyczące raportów stworzonych z udziałem AI to:
- Zwięzłość, bez zbędnych informacji, z przedstawieniem sedna i ważnych szczegółów na początku.
- Tylko czysty tekst, bez znaczników Markdown i dekoracji.
- Zrozumienie modelu zagrożeń i wskazanie weryfikowanych faktów (na przykład „błąd pozwala każdemu użytkownikowi uzyskać CAP_NET_ADMIN”), a nie teoretycznych spekulacji i domysłów dotyczących konsekwencji podatności.
- Przed przesłaniem raportu należy dokładnie przetestować działanie exploita stworzonego za pomocą AI oraz upewnić się, że problem można powtórzyć.
- Zastosowanie AI do opracowania i testowania poprawki dla zidentyfikowanego problemu.
Z danych statystycznych wynika, że większość raportów błędów przesyłanych jako naprawy luk w zabezpieczeniach w rzeczywistości nimi nie jest i powinny być traktowane w zwykłym porządku jako zwykłe błędy. Model zagrożeń jądra Linux opisuje, w jaki sposób rozróżnić luki i normalne błędy. Wśród możliwości i gwarancji, których naruszenie można uznać za lukę w zabezpieczeniach są:
- Izolacja na poziomie użytkowników: dostęp do plików tylko dla właściciela, pamięć procesu niedostępna dla innych użytkowników, ptrace zablokowane dla obcych procesów, izolacja IPC i komunikacji sieciowej.
- Ochrona oparta na capabilities: bez CAP_SYS_ADMIN nie można zmieniać konfiguracji jądra, pamięci, stanu systemu; bez CAP_NET_ADMIN nie można zmieniać ustawień sieciowych ani przechwytywać ruchu; bez CAP_SYS_PTRACE nie można śledzić procesów innych użytkowników.
- Przestrzeń nazw identyfikatorów użytkowników (CONFIG_USER_NS) pozwala nieuprzywilejowanym użytkownikom tworzyć własne izolowane środowiska, które nie mogą wpływać na globalną przestrzeń nazw, na przykład nie mogą zmieniać czasu, ładować modułów ani montować urządzeń blokowych.
- Interfejsy debugowania (/proc/kmsg, perf, debugfs), przez które można uzyskać dostęp do poufnych informacji, są dostępne tylko po wyraźnym udzieleniu dostępu przez administratora.
Możliwości, które nie są uznawane za luki w zabezpieczeniach:
- Użycie przestarzałych gałęzi jądra.
- Kompilacja z włączonymi opcjami dla programistów lub obniżającymi bezpieczeństwo (na przykład CONFIG_NOMMU).
- Ustawienie niebezpiecznych ustawień sysctl, opcji wiersza poleceń, praw dostępu w FS, capabilities lub otwarcie nieuprzywilejowanym użytkownikom dostępu do uprzywilejowanych interfejsów (na przykład dostęp do zapisu w procfs i debugfs).
- Problemy w funkcjach przeznaczonych tylko do tworzenia i debugowania jądra, takich jak LOCKDEP, KASAN i FAULT_INJECTION, które nie są przeznaczone do włączania w konfiguracjach roboczych.
- Problemy z sterownikami, modułami i podsystemami znajdującymi się w sekcji STAGING lub oznaczonymi jako eksperymentalne, niebezpieczne lub nie działające.
- Użycie zewnętrznych modułów jądra lub nieoficjalnych forków jądra.
- Wymóg nadmiernych uprawnień, takich jak konieczność wykonywania działań z uprawnieniami root lub od użytkownika posiadającego uprawnienia CAP_SYS_ADMIN, CAP_NET_ADMIN, CAP_SYS_RAWIO i CAP_SYS_MODULE.
- Teoretyczne ataki, które wymagają warunków laboratoryjnych, miliardów prób, emulacji lub modyfikacji sprzętu, nieproporcjonalnych kosztów i nierealistycznych konfiguracji (na przykład systemy z dziesiątkami tysięcy rdzeni CPU).
- Obchodzenie mechanizmów ochrony (np. ASLR) bez demonstracji exploita. Brak sprawdzeń argumentów i kodów błędów, które nie mają oczywistych konsekwencji.
- Losowe wycieki informacji, które nie są kontrolowane przez atakujących, takie jak pozostałe dane w komunikatach o błędach i wycieki adresów/wskaźników na pamięć jądra bez bezpośredniej możliwości ich wykorzystania.
- Błędy przy montowaniu uszkodzonych obrazów dysków, jeśli sterownik nie jest zadeklarowany jako nadający się do użycia z niezaufanymi nośnikami. Problemy z obrazami dysków, które można zidentyfikować i naprawić za pomocą narzędzia fsck.
- Ataki wymagające fizycznego dostępu do sprzętu, modyfikacji sprzętu lub podłączenia urządzeń sprzętowych, takich jak karty do ataku na DMA i analizatory logiczne, jeśli system nie jest specjalnie skonfigurowany w celu ochrony przed tego rodzaju atakami (IOMMU).
- Regresje z funkcjonalnością i wydajnością, które można usunąć przez dostosowanie uprawnień i limitów.
Źródło: opennet.ru
