O tysiąc mniej dróg do uprawnień root

Badania bezpieczeństwa, które kiedyś wymagały osobnej, długotrwałej analizy każdego wykrytego problemu, coraz częściej można prowadzić jako systematyczny proces. W tym dokumencie opisujemy jedno z naszych przedsięwzięć w tym obszarze.

Wykrywanie luk coraz łatwiej skalować, ale ustalanie priorytetów i walidacja pozostają wąskimi gardłami procesu. Zbudowaliśmy prototyp do wyszukiwania luk bezpieczeństwa w jądrze Linuksa w kontrolowanym środowisku badawczym. Nasz prototyp zidentyfikował i przeanalizował 2308 potencjalnych luk w jądrze Linuksa, dynamicznie odtworzył 1724 luki oraz opracował 948 exploitów lokalnej eskalacji uprawnień (LPE), które mogły pozwolić lokalnemu użytkownikowi bez specjalnych uprawnień uzyskać dostęp root.

Na podstawie tych dowodów ustaliliśmy kolejność zgłaszania luk i opracowaliśmy propozycje poprawek do weryfikacji przez opiekunów projektu. Zgodnie z zaleceniami społeczności jądra Linuksa zaczęliśmy od luk krytycznych. Współpracujemy z partnerami Patch the Planet nad kolejnymi raportami i poprawkami.

W czerwcu, w ramach naszej inicjatywy Patch the Planet, poinformowaliśmy, że GPT‑5.5 Cyber zidentyfikował luki w jądrze Linuksa i opracował 24 exploity lokalnej eskalacji uprawnień, aby je potwierdzić i zgłosić. Rozwinęliśmy te prace w proces oparty na nadchodzącym modelu do cyberbezpieczeństwa, obejmujący wykrywanie luk, walidację dynamiczną, ocenę możliwości wykorzystania oraz generowanie poprawek. Po jego zakończeniu badacze zweryfikowali wyniki i zgłosili wykryte luki wraz z poprawkami.

Jądro Linuksa stanowi podstawę urządzeń z Androidem, infrastruktury chmurowej, superkomputerów i innych systemów używanych przez miliardy ludzi. Liczące ponad 40 mln linii kodu jądro ma rozległą powierzchnię ataku obejmującą wywołania systemowe, obsługę sieci, systemy plików i sterowniki urządzeń. Wybraliśmy Linuksa, aby zbadać, jak skutecznie pionierskie modele potrafią znajdować luki i wykazywać ich wpływ na bezpieczeństwo w bazie kodu o takiej skali i znaczeniu.

Początkowy etap wykrywania luk wskazał tysiące potencjalnych problemów — zbyt wiele, aby badacze bezpieczeństwa mogli je ręcznie przejrzeć i ocenić. Wyzwaniem operacyjnym w naszym procesie nie było samo wykrywanie luk, lecz ustalenie, które z nich da się odtworzyć, jaką granicę bezpieczeństwa naruszają i które wymagają najpilniejszej uwagi opiekunów projektu.

Misją zespołu Cyber w OpenAI jest zwiększanie bezpieczeństwa oprogramowania, od którego zależy funkcjonowanie współczesnego świata. Przedstawiamy koszty korzystania z API na poszczególnych etapach, aby badacze mogli oszacować zasoby potrzebne do odtworzenia i rozwinięcia naszych badań. Podane kwoty odnoszą się do modeli, konfiguracji docelowych i procesu wykorzystanych w tej analizie. Naszym nadrzędnym celem jest wspieranie specjalistów ds. bezpieczeństwa w wykrywaniu i usuwaniu luk, tak aby ograniczyć możliwości atakujących i utrudnić im przeprowadzanie ataków, zwiększając ich koszty.

Warto też zaznaczyć, że w tym badaniu skupiliśmy się na metodologii i pomiarze możliwości modeli, a nie na kosztach. Oczekujemy, że odpowiednie dopracowanie otoczenia operacyjnego mogłoby znacząco obniżyć koszty na każdym etapie. Podane przez nas kwoty należy więc traktować raczej jako górną granicę.

Nasz prototyp do badania luk realizuje pięcioetapowy proces, którego podstawą jest nadchodzący model do cyberbezpieczeństwa:

• Wykrywanie luk: Agenty identyfikują części bazy kodu istotne dla bezpieczeństwa i skanują je pod kątem potencjalnych luk.

• Walidacja dynamiczna: Agenty próbują odtworzyć każdą potencjalną lukę w izolowanym środowisku i zachowują dowody z wykonania kodu. Wynikiem tego kroku są odtworzone i potwierdzone luki.

• Ocena możliwości wykorzystania: Agenty sprawdzają, czy potwierdzone luki mogą umożliwić ujawnienie informacji lub lokalną eskalację uprawnień.

• Generowanie poprawek: Agenty generują poprawki usuwające każdą zidentyfikowaną lukę.

• Weryfikacja przez badaczy: Badacze bezpieczeństwa sprawdzają exploit, poprawkę i proponowaną ocenę wagi luki przed zgłoszeniem jej opiekunom projektu.

Na końcu procesu system kompletuje analizę przyczyny źródłowej, minimalny kod demonstracyjny wywołujący awarię, propozycję poprawki i pełny exploit. Pomaga to badaczom ocenić wagę luki i przekazać poprawki do głównego projektu.

Nie każda linia kodu jądra Linuksa ma znaczenie dla bezpieczeństwa. Nasz system korzystał z zespołu agentów zwiadowczych, które identyfikowały szczególnie istotne obszary audytu, a następnie przekazywały je agentom analitycznym do skanowania pod kątem luk.

Agenty zwiadowcze przeglądają każdy folder i plik, po czym wybierają obszary do audytu na podstawie ich dostępności dla użytkowników z niskimi uprawnieniami oraz znaczenia dla bezpieczeństwa.

Na tym etapie wytypowano 5034 obszary audytu, obejmujące około 2,8 mln linii kodu, czyli około 7% całej bazy kodu jądra Linuksa. Znacznie obniżyło to koszt audytu bezpieczeństwa w porównaniu z analizą całej bazy kodu. Ten krok zużył środki na API o wartości 3426 USD.

Następnie agenty analityczne przeanalizowały każdy obszar audytu i wskazały potencjalne luki, stosując proces podobny do tego we wtyczce Codex Security⁠(otwiera nowe okno). W ogólnym zarysie agenty analityczne czytają kod przydzielonego obszaru audytu, aby zrozumieć jego działanie, określić model zagrożeń i poszukać w nim luk.

W ciągu 12 godzin agenty analityczne wskazały 2308 potencjalnych luk po usunięciu duplikatów. Ten etap zużył środki na API o wartości 316 549 USD.

Potencjalna luka to nie to samo co luka potwierdzona. Przy tej skali ręczne zbadanie każdego raportu przez nasz zespół badawczy jest niepraktyczne.

Dlatego skupiliśmy się na walidacji luk, które: a) były dostępne dla użytkownika z niskimi uprawnieniami, b) nie wymagały specjalnych uprawnień typu capabilities oraz c) dawały mierzalne dowody uszkodzenia pamięci.

Dla każdej potencjalnej luki agent weryfikujący generował kod demonstracyjny i uruchamiał go w izolowanej maszynie wirtualnej z jądrem Linuksa wyposażonym w Kernel Address Sanitizer (KASAN). Agent obserwował zarówno dane wyjściowe programu, jak i konsolę systemową, a następnie iteracyjnie dopracowywał kod demonstracyjny, aż odtworzył zgłoszone zachowanie lub wyczerpał możliwe sposoby jego wywołania.

W ciągu 30 godzin nasz system odtworzył 1724 luki, czyli około 74,7% z 2308 potencjalnych luk. Sam statyczny przegląd kodu może dawać fałszywe alarmy, dlatego zrobiły na nas wrażenie trafność agentów analitycznych i skuteczność agentów weryfikujących, które autonomicznie stworzyły działające kody demonstracyjne dla niemal trzech czwartych potencjalnych luk.

Większość pozostałych przypadków wymagała podwyższonych uprawnień lub nie dała się odtworzyć w wyznaczonym czasie z powodu trudnych do wywołania warunków wyścigu, szczególnych warunków wyzwalających (np. konieczności niepowodzenia alokacji w konkretnej linii) lub czasochłonnej walidacji (np. przepełnienia licznika odwołań). Tylko 3,1% przypadków wynikało z błędnej analizy modelu, w której zgłoszona luka zakładała wystąpienie niemożliwego warunku.

Etap walidacji zużył łącznie środki na API o wartości 73 330 USD. Zaobserwowaliśmy, że nasz proces walidacji, wymagający wygenerowania kodu demonstracyjnego w celu potwierdzenia rzeczywistej luki, był droższy niż wydanie rekomendacji wyłącznie na podstawie analizy statycznej. Koszty próby potwierdzenia rzeczywistej luki i fałszywego alarmu były przy tym podobne. Wcześniejsze eliminowanie fałszywych alarmów znacząco poprawia więc efektywność kosztową procesu.

Walidacja potwierdza istnienie luki, ale nie określa, jak pilnie należy ją usunąć. Na przykład luka umożliwiająca lokalną eskalację uprawnień zasługuje na wyższy priorytet niż taka, która może jedynie spowodować lokalną odmowę usługi. Po potwierdzeniu 1724 luk kolejnym zadaniem było wskazanie tych o potencjalnie największym wpływie na bezpieczeństwo.

Agent wstępnej selekcji przeprowadził statyczny przegląd każdego raportu, dziennika awarii i odpowiedniego kodu źródłowego. Celowo stosował łagodne kryteria, aby nie odrzucać potencjalnie poważnych luk, jednocześnie odsiewając przypadki bez wiarygodnej ścieżki wykorzystania. Zawęziło to wyniki do 313 potencjalnych wycieków informacji i 1238 potencjalnych przypadków lokalnej eskalacji uprawnień.

Następnie agenty tworzące exploity (ExploitDev) przetestowały te przypadki w izolowanych maszynach wirtualnych z zabezpieczeniami włączonymi w standardowej dystrybucji Linuksa, w tym Supervisor Mode Execution Prevention (SMEP), Supervisor Mode Access Prevention (SMAP), Kernel Address Space Layout Randomization (KASLR) i HARDENED_USERCOPY. Pomogło to uniknąć nierealistycznych ocen, opartych na założeniu wyłączenia zabezpieczeń.

Agenty opracowały 291 kodów demonstracyjnych wycieku informacji i 1169 działających exploitów lokalnej eskalacji uprawnień, które mogły zapewnić lokalnym użytkownikom bez specjalnych uprawnień dostęp root.

Przeprowadziliśmy analizę wariantów i opracowaliśmy 948 odrębnych poprawek dla luk wykorzystywanych przez te exploity. Na tej podstawie określamy łączną liczbę unikalnych luk LPE. Opracowanie skutecznego exploita zużywało średnio środki o wartości 359 USD. Dzięki temu osoby odpowiedzialne za ochronę mogą stosunkowo tanio sprawdzać możliwość wykorzystania znalezionych luk.

Agent wstępnej selekcji luk zużył środki na API o wartości 44 194 USD. Etap wykorzystywania luk zużył łącznie środki na API o wartości 775 929 USD: 84 929 USD na analizę potencjalnych wycieków informacji i 691 000 USD na potencjalne przypadki lokalnej eskalacji uprawnień.

Średnio analiza potencjalnego przypadku lokalnej eskalacji uprawnień (558 USD) była około dwukrotnie droższa niż analiza potencjalnego wycieku informacji (271 USD). Wynika to z tego, że kody PoC wycieku informacji pochodziły z etapu walidacji i wymagały mniejszych modyfikacji, aby dało się ich użyć w exploicie. Natomiast opracowanie exploita dla potencjalnej luki LPE wymagało wielu dodatkowych kroków, takich jak zaplanowanie strategii wykorzystania, wskazanie podatnych obiektów, obejście zabezpieczeń i innych działań. Zauważyliśmy też, że nieudane próby wykorzystania luk (średnio 3922 USD w 69 przypadkach) kosztowały znacznie więcej niż udane (średnio 360 USD w 1169 przypadkach). Przyczyną było kilka luk trudnych do wykorzystania (np. warunki wyścigu). Określenie rozsądnego warunku przerwania pracy, na przykład zakończenia próby po godzinie bez postępów, znacznie obniżyłoby koszt działania ExploitDev.

Dla każdej potwierdzonej luki system generuje również poprawkę. Dostarczamy modelowi odpowiedni kod źródłowy i instruujemy go, aby stosował dobre praktyki przy jej tworzeniu, takie jak przeprowadzanie kontroli statycznej, przestrzeganie konwencji programistycznych stosowanych w sąsiednim kodzie oraz analiza wariantów w celu upewnienia się, że poprawka jest kompletna.

Zgodnie z sugestią społeczności jądra Linuksa wysłaliśmy już setki raportów i poprawek dotyczących luk krytycznych. Wspólnie z partnerami Patch the Planet pracujemy nad stopniowym udostępnianiem poprawek usuwających pozostałe luki. Te prace są częścią naszego szerszego zobowiązania do wspierania projektów open source w ramach programu Daybreak.

W tej sekcji dzielimy się wnioskami, refleksjami i dodatkowymi analizami z tego badania.

Podczas tego badania obserwowaliśmy, jak opiekunowie Linuksa szybko usuwają luki, by chronić użytkowników. Skanowanie przeprowadzono w połowie października 2026 r. na najnowszym jądrze Linuksa. Gdy po 10 dniach zakończyły się autonomiczne skanowanie i ręczna analiza, 61 luk LPE było już załatanych w głównym projekcie, 43 miały wstępne poprawki, a 299 było publicznie zgłaszanych i omawianych.

Bardzo doceniamy opiekunów Linuksa, którzy intensywnie pracują nad usuwaniem wykrytych luk, a także całą społeczność specjalistów w dziedzinie bezpieczeństwa, którzy dzielą się swoimi ustaleniami. Właśnie takich wspólnych działań potrzeba, by zabezpieczać oprogramowanie na całym świecie. Szybkie tempo ujawniania i łatania luk podkreśla też, jak ważne jest, aby użytkownicy i firmy na bieżąco aktualizowali oprogramowanie.

Wniosek: Automatyczna weryfikacja zgłoszeń powinna uwzględniać szybki cykl łatania luk. Ponowna walidacja ustaleń względem najnowszego kodu, w tym kodu włączonego do projektu po pierwotnym skanowaniu, pomaga unikać zduplikowanych lub nieaktualnych raportów. Pozwala to skupić uwagę na nierozwiązanych lukach i dostarcza opiekunom projektu dowody, na podstawie których mogą działać, bez dokładania im zbędnej pracy przy weryfikacji.

Podczas prac nad naszym systemem, pod koniec lipca 2026 r., model GPT‑5.6 Sol znalazł i wykorzystał 166 unikalnych luk LPE, zużywając w całym procesie środki na API o wartości 513 690 USD.

W drugim skanowaniu, w połowie października 2026 r., nowszy model do cyberbezpieczeństwa znalazł i wykorzystał 948 unikalnych luk LPE, zużywając w całym procesie środki na API o wartości 1 213 430 USD. W obu kampaniach skanowaliśmy aktualną wówczas wersję gałęzi master jądra Linuksa.

Wniosek: W miarę wzrostu możliwości modeli należy ponownie skanować kod poddany już audytowi. Model o większych możliwościach może odkryć luki pominięte przez wcześniejsze modele, nawet przy użyciu tego samego badawczego otoczenia operacyjnego.

Wybraliśmy do analizy próbę 166 exploitów opracowanych przez agenty i sprawdziliśmy, jakie techniki w nich zastosowano. Według naszej wiedzy agenty zastosowały w nich 10 nowych technik. Przedstawiliśmy je również niezależnym ekspertom specjalizującym się w wykorzystywaniu luk w jądrze Linuksa, którzy także wcześniej się z nimi nie spotkali.

Spośród tych 10 technik dwie polegają na użyciu nowych trwałych obiektów o elastycznym rozmiarze, którymi model zapełniał docelową pamięć podręczną jądra; dwie to nowe techniki przygotowywania układu stron pamięci, zwiększające niezawodność exploita; pięć to nowe techniki oparte wyłącznie na danych, pozwalające uzyskać eskalację uprawnień bezpośrednio lub przez zapis w dowolnym miejscu pamięci; ostatnia technika wykorzystuje możliwość pomylenia dowolnych typów. Ze względów bezpieczeństwa nie udostępniamy w tym wpisie pełnych szczegółów technicznych tych nowych technik wykorzystywania luk.

Wniosek: Pionierskie modele nie ograniczają się do rozpoznawania znanych wzorców podatnego kodu ani do stosowania znanych technik wykorzystywania luk — wykazują kreatywność i stosują nowe podejścia.

Ważną częścią misji naszego zespołu jest pomiar kosztów wykrywania i wykorzystywania luk oraz posługiwanie się tymi danymi przy wskazywaniu kierunków inwestycji w ochronę. Naszym celem jest pomaganie osobom odpowiedzialnym za ochronę w usuwaniu luk, zanim wykorzystają je atakujący, oraz podnoszenie kosztów ataków na oprogramowanie do poziomu, przy którym przestają się opłacać. Pomiar kosztów wykorzystywania luk pomaga nam ocenić, jak to wyzwanie zmienia się wraz ze wzrostem możliwości modeli. W tej sekcji porównujemy koszt przebiegu naszego procesu z nagrodami oferowanymi w programach bug bounty za zidentyfikowane luki.

Docelowe maszyny wirtualne w naszym eksperymencie działały pod kontrolą standardowego systemu operacyjnego dla komputerów osobistych, bez celowego osłabiania zabezpieczeń, przy takim samym modelu zagrożeń jak w konkursach cyberbezpieczeństwa (np. Pwn2Own⁠(otwiera nowe okno), TyphoonPWN⁠(otwiera nowe okno)). W przeszłości Pwn2Own i TyphoonPWN oferowały nagrody za exploity lokalnej eskalacji uprawnień w jądrze Linuksa w wysokości odpowiednio 20 000 i 70 000 USD. Zastosowanie tych historycznych stawek do 948 exploitów daje hipotetyczną wycenę 18,9–66,3 mln USD, czyli około 16–55 razy więcej niż koszt naszego procesu.

Przetestowaliśmy też nasz system w kontekście programu nagród za wykrywanie luk w zabezpieczeniach kernelCTF⁠(otwiera nowe okno) firmy Google, którego celem jest jądro Linuksa ze wzmocnionymi zabezpieczeniami i ograniczoną powierzchnią ataku. Uruchomiliśmy proces na najnowszej wersji jądra Linuksa w środowisku kernelCTF. Ponieważ wersja ta była niezgodna z zabezpieczeniem SLAB_VIRTUAL w kernelCTF, usunęliśmy je z konfiguracji. Uzyskaliśmy 25 kodów demonstracyjnych wycieku informacji i 21 exploitów lokalnej eskalacji uprawnień. Dla porównania: do momentu pisania tego tekstu program kernelCTF przyjął w 2026 r. 26 potwierdzonych exploitów LPE wykorzystujących luki zero-day. Cała kampania trwała 112 godzin i zużyła środki na API o wartości około 32 936 USD, z czego 83,7% kosztów API przypadało na wykrywanie luk. Gdyby program przyjął te 21 luk, przyniosłoby to nagrodę w wysokości około 1,5 mln USD, czyli około 45 razy więcej niż poniesiony koszt.

Wniosek: Według publicznie dostępnych kwot nagród, przy użyciu obecnych modeli o możliwościach w zakresie cyberbezpieczeństwa, nasz proces badania luk był w czasie tego badania rentowny netto. Osoby odpowiedzialne za ochronę powinny proaktywnie analizować swoje oprogramowanie, aby wykorzystywanie jego luk stało się dla atakujących nieopłacalne.

Podczas oceny możliwości wykorzystania luk agenty ExploitDev otrzymywały raport o luce i zadanie stworzenia w pełni działającego exploita. Nasz system oznaczał lukę jako wykorzystaną, jeśli udało się uzyskać powłokę z uprawnieniami root. Podczas jednego z wczesnych przebiegów etap wykorzystywania luk zgłosił 200 skutecznych exploitów lokalnej eskalacji uprawnień. Po weryfikacji przez badaczy okazało się jednak, że 20 z nich uzyskało uprawnienia root przez inną lukę zero-day niż przydzielona. Sugeruje to, że nawet skuteczne wykorzystanie luki przez agenty wymaga właściwej walidacji.

Następnie zaostrzyliśmy ograniczenia zadania i dodaliśmy niezależną kontrolę potwierdzającą, że każdy końcowy exploit wykorzystuje przydzieloną mu lukę.

Wniosek: W autonomicznych badaniach bezpieczeństwa należy weryfikować nie tylko sam wynik, ale też sposób jego uzyskania. Izolacja, monitorowanie i niezależne kontrole są niezbędnymi zabezpieczeniami.

Na początku badań rozważaliśmy, czy rozbudować orkiestrację wokół agenta, aby zwiększyć jego możliwości w zakresie cyberbezpieczeństwa. Nasz wynik sugerował, że modele o większych możliwościach wymagają prostszej orkiestracji i mniej prowadzenia krok po kroku. Niewielka poprawa nie uzasadniała zaś kosztów utrzymania. W rezultacie postanowiliśmy usunąć rozbudowaną orkiestrację.

W eksperymencie porównaliśmy GPT‑5.5 Cyber i GPT‑5.6 Cyber. Z naszych obserwacji wynikało, że model GPT‑5.5 Cyber nie zawsze trafnie rozpoznawał, kiedy i jak stosować znane techniki wykorzystywania luk w jądrze Linuksa. Zebraliśmy więc 103 techniki w formacie przystępnym dla modelu, udostępniliśmy je w środowisku agenta i poleciliśmy mu z nich korzystać. W grupie 63 potencjalnie możliwych do wykorzystania luk zwiększyło to skuteczność z 76,2% do 88,9%.

Gdy powtórzyliśmy eksperyment z GPT‑5.6 Cyber, model lepiej radził sobie z samodzielnym znajdowaniem, wybieraniem i stosowaniem odpowiednich technik. Usunęliśmy orkiestrację technik i umiejętności. Proces z GPT‑5.6 Cyber i uproszczoną orkiestracją osiągnął lepsze wyniki niż proces z GPT‑5.5 Cyber i bardziej rozbudowanymi mechanizmami wsparcia. Przywrócenie dodatkowej warstwy technik dla GPT‑5.6 Cyber dało jedynie niewielką poprawę o 1,5 punktu procentowego.

Wniosek: Wraz ze zmianami możliwości modelu bazowego należy ponownie oceniać orkiestrację i otoczenie operacyjne. Mechanizmy wsparcia, które istotnie poprawiają wyniki jednej generacji modeli, mogą wnosić niewiele w przypadku lepszego modelu. Należy więc zestawić ich korzyści z kosztami utrzymania.

Początkowo, po bezpośrednim poleceniu wygenerowania propozycji poprawki, model tworzył funkcjonalnie poprawne rozwiązania, które blokowały działanie kodu demonstracyjnego, ale czasem wprowadzały inne problemy: nadmiarowy kod, potencjalne pogorszenie wydajności lub odstępstwa od konwencji kodowania. Niekiedy nie sprawdzał też powiązanego kodu pod kątem wariantów tej samej luki, co prowadziło do niekompletnych poprawek.

Dodatkowe instrukcje i kolejne udoskonalenia procesu generowania poprawek podniosły ich jakość. Sugeruje to, że przy odpowiednim podejściu poprawki bezpieczeństwa generowane przez AI mogą być prawidłowe, minimalne i zgodne z istniejącymi konwencjami kodu. To obszar intensywnych badań. Uważamy, że przyszłe modele ułatwią ten proces i zwiększą jego skuteczność. W kilku przypadkach nasz prototyp badawczy potrafił też wykryć problemy w poprawkach napisanych przez ekspertów. Zostały one następnie usunięte przed włączeniem poprawek do projektu.

Wniosek: Modele mogą przyspieszyć łatanie luk, ale umiejętności i otoczenia operacyjne służące do tego celu mogą wymagać iteracyjnego doskonalenia, aby poprawki niezawodnie spełniały zarówno wymagania funkcjonalne, jak i pozafunkcjonalne. Zalecamy też używanie modeli do przeglądu poprawek napisanych przez ludzi i AI z perspektywy atakujących. Może to ujawnić takie problemy jak możliwość obejścia poprawki, pominięcie innych ścieżek lub wariantów ataku i wiele innych.

Podczas przebiegu w kernelCTF nasz prototyp badawczy, oprócz 21 exploitów wykorzystujących luki zero-day w jądrze Linuksa, znalazł i wykorzystał też lukę w QEMU TCG. Agent analityczny otrzymał zadanie zbadania kodu wejściowego wywołań systemowych. Pisząc programy do eksperymentowania z przejściami między poziomami uprawnień, natrafił na nieoczekiwaną awarię jądra. Przeanalizował awarię i ustalił, że problem leży w QEMU TCG, mimo braku dostępu do kodu źródłowego QEMU, po czym uwzględnił lukę w raporcie. Następnie agent ExploitDev z powodzeniem opracował dla tej luki exploit lokalnej eskalacji uprawnień. Odkryliśmy tę podatność QEMU podczas ręcznej analizy exploitów i potwierdziliśmy, że została już naprawiona w głównym projekcie QEMU, ale nie w wydanej kompilacji użytej podczas eksperymentu.

Wniosek: Pionierskie modele o możliwościach w zakresie cyberbezpieczeństwa potrafią znajdować luki w infrastrukturze testowej. Zalecamy przetestowanie każdej części infrastruktury przed rozpoczęciem ofensywnych badań nad lukami. Proaktywnie przetestowaliśmy naszą infrastrukturę, ujawniając i łatając wiele luk w projektach takich jak Kata Containers, Moby/Docker, gVisor i innych.

Naszym celem jest przekucie rosnących możliwości modeli w trwałą przewagę dla osób dbających o bezpieczeństwo internetu. Badanie to pokazuje, że rosnące możliwości pionierskich modeli w dziedzinie cyberbezpieczeństwa pozwalają skutecznie szukać luk w złożonym oprogramowaniu, takim jak jądro Linuksa. Wzmacnianie zabezpieczeń kluczowych projektów oprogramowania, takich jak Linux i inne projekty open source, może chronić wiele korzystających z nich systemów i użytkowników.

W ramach Patch the Planet, inicjatywy programu Daybreak, zamierzamy rozszerzyć te badania na kolejne kluczowe projekty oprogramowania oraz wspólnie z opiekunami projektów i partnerami w dziedzinie bezpieczeństwa opracować niezawodne, automatyczne łatanie luk. Chcemy stopniowo ograniczać możliwości atakujących i podnosić koszty wyszukiwania oraz wykorzystywania luk, aż oczekiwany zysk przestanie uzasadniać atak.

Każda generacja modeli powinna pomagać nam tworzyć oprogramowanie, które kolejnej generacji modeli będzie trudniej złamać. Będziemy nadal pracować nad bezpiecznym internetem, w którym każdy może czerpać radość z tworzenia.