Hogyan használjuk a /goal-t a Patch the Planet hibáinak keresésére

A Codex /goal funkciója felerősíti a hibakeresést, de a jó eredmények elérése megfelelő kérdést, megfelelő terjedelmet és a megfelelő számú kimenetet igényel egy futás során. A Patch the Planet keretében, amely az OpenAI-val közös kezdeményezésünk a nyílt forráskódú szoftverekben rejlő hibák felkutatására és javítására, a Codexet a világ legszélesebb körben használt, alaposan auditált kódalapok, például Rust, curl és zlib irányába mutattuk. Egy eszköz újra és újra felmerült belső hibajelentési csatornáinkban: /goal, amely a Codexnek egy nyílt végű célt ad, és lehetővé teszi, hogy függetlenül dolgozzon a siker feltételei felé. Íme néhány kiemelkedő eredmény: a /goal a benyújtott minden Rust hibát megtalált, beleértve egy soundness hibát és egy rossz fordítást, amely most javítva lett a Rust 1.98-ban, egyetlen változatelemzési csővezetéken keresztül. Minden projekt korábbi CVE-jét Semgrep szabályokká alakította, amelyeknek a sebezhető verzión működniük kellett, míg a javított verzión csendben kellett maradniuk, majd 11 változati találatot azonosított több projektben. Felfedezett két potenciálisan magas súlyosságú jogosultság-emelési hibát a Keycloak SAML komponensében egy felfedező futás során. A Patch the Planet első néhány hetében mérnökeink függetlenül három technika felé terelődtek el a /goal használatára. Megállapítottuk, hogy a /goal legjobban kihasználva a kérdést mint specifikus siker kritériumok halmazát kell kezelni, nem pedig utasítások halmazaként. (Megjegyzendő, hogy ez a blogbejegyzés a /goal-t általában a cél-alapú kérdezésre utal.) A Codex a legjobban ismeri a Codex-et, és a /goal használatának művészete a kérdés megtervezése. Belsőleg a leggyakrabban ismételt /goal tippünk az volt, hogy használjuk a Codexet minden /goal kérdés megírásához. Átadunk a Codexnek fenyegetésmodellezési fájlokat és a keresett kontextusokat, majd megmondjuk neki, hogy írja meg a cél kérdést. Mint korábban említettük, a /goal egy eszköz, amelyet a Codex önállóan használhat, és néhány mérnök teljesen leállította a kézi célok beírását. $goal-kérdés a fenyegetésmodel alapján írjon célt a távoli támadó által kihasználható egyetlen kritikus probléma (RCE) megtalálásához a kubernetes-client számára. A kubernetes-client normál konfigurációval használatos, rosszindulatú távoli felhasználók kihasználása mellett. Ez működik, mert a Codex jobban ismeri a célt és saját hajlamait, mint ahogyan azt mi előre meg tudnánk határozni. Le tudja fordítani a fenyegetésmodellt konkrét, tesztelhető siker kritériumokká, nevesíteni tudja a prioritásokat érdemlő kód útvonalakat, és elég pontosan tudja megfogalmazni az eredményt, hogy egy futás tényleg konvergáljon. Ezt a módot a célra általában szorosabbnak tartják, mint amit hideg írásban írnánk, és az idő töredékét igényli. Ha hagyjuk, hogy a modell megtervezze a célt, akkor egy olyan rést is bezár, amelyet egyébként kihagynánk. Bármilyen kimenetet, amelyet meghatároz az ember, olyan módon lehet kielégíteni, ahogyan nem szándékozott, és a modell gyakran az első, aki észreveszi, hol vannak az egyszerű megoldások. Most, amikor megkérjük a Codexet, hogy dolgozzon ki egy célt, megkérjük, hogy végezzen el egy vörös csapat tesztet a saját célján, azaz azonosítja azokat a módokat, ahogyan egy jövőbeli modell lustán dolgozhat, és felülvizsgálja a kritériumokat a futás megkezdése előtt. Olyan eszközöket is létrehoztunk, amelyek megkönnyítik a Codex számára, hogy ellenőrizze a saját munkáját. Például észrevettük, hogy a Codex hajlamos kihagyni az egész kódalap átolvasását, még akkor is, ha kifejezetten kérik. Létrehoztunk egy aicov nevű eszközt, amely nyomon követi, hogy a Codex mely kódsorokat olvasott el valójában, így nem tud “csalni”. Ez egy iteratív folyamat. Ahogy egyre több rövidítést találunk, amelyet egy modell alkalmaz, kizárjuk őket a következő kérdés verziójából. Egy jó cél megnevezi az eredményt, pontosan definiálja azt, majd állandósítja: /goal Auditálja a kubernetes-client tárolót ebben a munkaterületen, hogy pontosan egy korábban nem bejelentett kritikus távoli kód végrehajtásának sebezhetőségét találja meg, amely elérhető a normál/ alapértelmezett klienskonfiguráció alatt egy rosszindulatú távoli felhasználó vagy szerver által, amely csak hálózati/API válaszokat, a kliens által legitim módon lehívott Kubernetes objektumokat vagy más távoli adatokat működtet a normál használat során. Először állítson össze egy tömör fenyegetésmodellt a reális távoli támadók belépési pontjairól és bizalomhatárokról, majd priorizálja a deserializációval, YAML/JSON/protobuf elemzéssel, dinamikus importálással/értékeléssel/sablon végrehajtással, archívum/fájl kicsomagolással, hitelesítési átirányításokkal, generált kliens horgokkal, websocket/exec/attach/port-forward streamekkel és alfolyamat vagy fájlrendszer hatásokkal foglalkozó kód útvonalakat. Ne tegyen fel feltételezéseket a helyi kubeconfig, CLI argumentumok, környezeti változók, telepített bővítmények, forráskód, hitelesítő adatok, privilegizált cluster/admin hozzáférés vagy korábbi kód végrehajtás felett; kifejezetten utasítson el olyan megállapításokat, amelyek ezekre a feltételekre támaszkodnak. Mielőtt elfogadna egy jelöltet, keressen helyi ismert eredmények fájlokban, valamint aktuális nyitott problémák/prs között duplikációk után, majd készítsen egy minimális biztonságos bizonyítékot, amely demonstrálja az attacker-controlled kód végrehajtást vagy egy közvetlen RCE primitívet a megadott normál konfiguráció alatt. Egy érvényes kritikus problémával álljon meg. Írja a megállapítást a ./findings/ mappába. Megállapítottuk, hogy a legjobb filozófia, ha annyi tokent költünk, amennyire szükség van az eredmény meghatározásához, és szinte semennyit nem mondunk a modellnek arról, hogyan érjük el azt. Ha a hibát fuzzing-on keresztül szeretné megtalálni, a “fuzzing használata” az a legmesszebb, ameddig menni lehet. “Építsen a meglévő fuzzing keretemre” vagy “építse egy új fuzzing keretet” mind rosszabb ajánlás. Lehet, hogy létezik egy meglévő keret, amely éppolyan jó. A cél, amely előírja az utat, garantálja, hogy a Codex soha nem követ más utat, és elveszíti azokat a megítélési és nyitott problémamegoldó képességeit, amelyek a /goal-t egyedivé teszik. Az eredmény kiválasztása fokozottabb figyelmet igényel, mert kalibráltnak kell lennie. Ha túlságosan specifikus, a Codexnek nincs elegendő információja a kereséshez, és az autonóm /goal futás értéke nem világos. Amikor a Codexnek megadtuk egy ismert hiba pontos gyökérokát és megkértük, hogy keressen változatokat, semmit sem talált. A terjedelem túl szűk volt. Amikor a bemenetet egyetlen mondatra csökkentettük, amely a keresendő hibák osztályát írta le az ismert hiba alapján, számos hibát tárt fel. 9-et jelentettünk, amelyek közül 3 már javítva és felforrasztva lett felül. Ha egy eredmény túl homályos, a modell olyan kimeneteket ad, amelyek nem egyeznek meg azzal, amit kerestünk. Az egyik legrosszabb /goal kérdés, amelyet a Patch the Planet során láttunk, az volt, hogy “keress hibákat [X]”. A modellnek nem volt módja megállapítani, mikor végzett. Csak folyamatosan futott, hibákat feltárva, amelyeknek nem volt valós hatásuk, és felesleges tokent pazarolt. A teljes kimenetdefiníció azt is meghatározza, hogy mi nem számít befejezettnek. A Patch the Planet nyílt forráskódú projektjei között van a világ legjobban auditált kódja, és többször is a /goal visszaérkezett “nincs hiba találva” válasszal. Ezt átmeneti eredménynek tekintjük, nem pedig befejezési feltételnek, és a célba beépítjük az állandóságot. A /goal hibakeresés legjobb forrása egy THREAT_MODEL.md fájl. Végül majdnem minden célunkhoz hivatkoztunk egy fenyegetésmodell fájlra, mert pontosan meghatározza, hogy mit jelent egy érvényes hiba anélkül, hogy elmagyarázná, hogyan kell találni őket. Minden nyílt forráskódú projekt számára javasoljuk, hogy hozzon létre egyet. Két versengő kimenet egy /goal kérdésben az egyenetlen optimalizálódáshoz vezet. Ezzel többször is találkoztunk, amikor egy cél egyszerre kért hibákat és lefedettséget. Amikor a “hibák keresése” és a “magas lefedettség elérése” szerepelt a kérdésben, a futás végül az egyik feladatot messze jobban teljesítette, mint a másikat. Ez volt a tapasztalatunk a /goal zlib auditálása során. A Codex folyamatosan a kódalap ugyanazon részére terelődött, a modell által elsőnek talált területeket fuzzolva, anélkül, hogy elérte volna a többit. Kezdeti ösztönünk az volt, hogy ezt javítsuk a kérdésben a lefedettség követelményeinek hozzáadásával, de a Codex ezután lefedettségre váltotta az optimalizálását, és a sebezhetőségek keresése nem volt túl eredményes. Amit helyette tettünk, az az volt, hogy teljesen áthelyeztük a lefedettséget a kérdésből. Azt kértük a Codextől, hogy először azonosítsa az öt legígéretesebb támadási felületet a kódalap átnézése után. Ezután minden szekcióhoz egy külön /goal ülést hoztunk létre a hibák megtalálására. Emellett hozzáadtunk egy teljesen nyitott ülést is melléjük, hogy bejárhassuk a kódalap olyan részeit, amelyeket a többi ügynök nem kapott meg. Ez a megközelítés lényegesen jobban működött. A Rust karbantartói azt feltételezték, hogy van egy csapat mérnök, aki a hibák felkutatásán dolgozik. Valójában csak egy mérnök volt, aki jól bánik a Codex /goal-lal. Az egyik mérnökünk, Kevin Valerio, létrehozott egy automatizált változatelemző rendszert a Rust fordító számára, kihasználva a /goal-t. A Patch the Planet során benyújtott minden Rust hibát ez hozott létre. A P-critical egy címke, amelyet a Rust karbantartói hoztak létre, hogy azonosítják a hibákat, amelyeket prioritásként kell kezelni a javításhoz és összeforrasztáshoz. A csővezeték olyan, hogy letölti az összes P-critical címkével ellátott problémát a rust-lang/rust tárolóból JSON formátumban. Egy irányító olvassa a problémákat, és külön ügynököt indít minden egyes kérdéshez. Egy kimenet minden ügynökre: ahelyett, hogy egyetlen ülést mondanánk, amelynek minden hibán végre kell hajtania a változatelemzést, az irányító egy Codex ülést hoz létre minden kérdéshez, mindegyik egy független feladatot futtatva, hogy megtalálja az egyetlen kimenetet. Minden ülés a Cél üzemmódban fut, egy szándékosan rövid kérdéssel, hogy egy biztonsági problémát találjon, amely ugyanazzal a gyökérokkal bír, mint az eredeti hiba a P-critical esetében. Egy mondatos leírást kap a kockázatról, nem pedig pontos gyökérokot egy teljes visszakereséssel, így a modellnek még van szabadsága a kódalap felfedezésére. Mielőtt bármely változatkeresés elkezdődne, egy biztonsági kapu megkérdezi, hogy a forráshiba valóban igazi sebezhetőség-e, és átirányítja, hogy kihagyja, no_variant vagy bug_found. Ezt a legfontosabb P-critical hibákra összpontosítjuk. Minden jelölt egy kétlépcsős hamis pozitív tesztverziós sornak van alávetve. Az első bíró ellenőrzi, hogy a hiba komoly biztonsági kockázatot jelent-e. A második, egy teljesen különböző modell, egy PoC-középpontú átmenetet futtat, és megköveteli, hogy a probléma potenciálisan okozhasson biztonsági problémákat, amelyek relevánsak a Rust fenyegetésmodell számára. Egy jelölt csak akkor érheti el az “érvényes megállapítás” szintet, ha mindkét teszt egyetértene. Az érvényes megállapítások egy utolsó emberi szűrőn keresnek. Mielőtt bármit megnyitnánk, duplikációs ellenőrzést végzünk. Csak azok a hibák kerülnek benyújtásra, amelyek felfelé megerősítettek és amelyek nem szerepelnek már a GitHub problémáiban. A hibák felkutatásához és javításához elengedhetetlen az emberi megítélés. A /goal kiadása óta ez egy erőteljes eszköz volt a hibakeresési munkánk fokozására. A Codex képes egyedi biztonsági infrastruktúrákat létrehozni, amelyek biztonsági kutatónak hetekbe telik, egy nap alatt. Gyorsabban képes átnézni ezer sor kódot, mint bármely ember. A /goal hűen üldözi azt a kimenetet, amelyet a modellnek megadunk, ami azt jelenti, hogy a futás döntése túlnyomórészt már a modell indulása előtt megszületik. De hatékonysága továbbra is egy szakértő tudásától függ, hogy tudja, hová kell nézni, ellenőrizze, hogy az eredményei megfelelnek egy jelenthető megállapításnak, és tudja, hogy a másik oldalon a fenntartók valójában mit akarnak látni érvényes sebezőségi nyilvános bejelentésként. A kérdés tervezése nagy része ennek, de csak akkor tudsz jó kérdést írni, ha pontosan tudod, mit keresel.