Njia elfu moja pungufu za kupata ruhusa za root

Utafiti wa usalama ambao hapo awali ulihitaji uchunguzi tofauti wa muda mrefu kwa kila matokeo sasa unaweza kufanywa kwa utaratibu maalumu kwa kiwango kinachozidi kuongezeka. Hati hii inachunguza mojawapo ya juhudi zetu katika eneo hili.

Inazidi kuwa rahisi kugundua udhaifu kwa kiwango kikubwa, lakini kupanga vipaumbele na kuthibitisha matokeo bado kunakwamisha mchakato. Tuliunda mfumo wa majaribio wa kutafuta dosari za usalama katika kiini cha Linux ndani ya mazingira ya utafiti yaliyodhibitiwa. Mfumo wetu wa majaribio ulitambua na kuchanganua matokeo ya awali 2,308 katika kiini cha Linux, ukazalisha tena udhaifu 1,724 kwa kuendesha msimbo, na ukaunda programu 948 za kuongeza ruhusa ndani ya mfumo (LPE) ambazo zingeweza kuruhusu mtumiaji wa mfumo asiye na ruhusa maalumu kupata ufikiaji wa root.

Tulitumia ushahidi huu kupanga udhaifu kwa kipaumbele cha kuripotiwa na tukatengeneza viraka vya kupendekeza kwa wasimamizi ili wavikague. Kwa kufuata mwongozo wa jumuiya ya kiini cha Linux, tulianza na udhaifu hatari zaidi na tunashirikiana na washirika wa Patch the Planet kuandaa ripoti na viraka zaidi.

Mwezi Juni, kama sehemu ya mpango wetu wa Patch the Planet, tulieleza kuwa GPT‑5.5 Cyber ilikuwa imetambua udhaifu katika kiini cha Linux na kuunda programu 24 za kuongeza ruhusa ndani ya mfumo ili kuuthibitisha na kuuripoti. Tulipanua kazi hiyo kuwa mchakato unaotumia muundo ujao wa usalama wa mtandao, unaojumuisha ugunduzi wa udhaifu, uthibitishaji kwa kuendesha msimbo, tathmini ya uwezekano wa kutumia udhaifu, na utengenezaji wa viraka. Ulipokamilika, watafiti walikagua matokeo na kuripoti udhaifu uliopatikana pamoja na viraka.

Kiini cha Linux ni msingi wa vifaa vya Android, miundombinu ya wingu, kompyuta zenye uwezo mkubwa sana na mifumo mingine inayotumiwa na mabilioni ya watu. Kwa kuwa na zaidi ya mistari milioni 40 ya msimbo, kiini kina sehemu nyingi zinazoweza kushambuliwa kupitia miito ya mfumo, mitandao, mifumo ya faili na viendeshi vya vifaa. Tulichagua Linux kuchunguza ufanisi wa miundo ya kiwango cha juu zaidi katika kupata udhaifu na kuonyesha athari zake kwa usalama katika msimbo wenye ukubwa na umuhimu huu.

Hatua ya kwanza ya ugunduzi wa udhaifu ilitoa maelfu ya matokeo ya awali, mengi sana kwa watafiti wa usalama kuyakagua na kuyachunguza wenyewe. Changamoto ya kiutendaji katika mchakato wetu wa kugundua udhaifu haikuwa ugunduzi wenyewe, bali kubaini ni matokeo yapi yangeweza kuzalishwa tena, yalivuka mpaka upi wa usalama, na yapi yalistahili kushughulikiwa kwanza na wasimamizi.

Dhamira ya timu ya Cyber ya OpenAI ni kusaidia kulinda programu ambazo ulimwengu unazitegemea. Tunaripoti gharama za API kwa kila hatua ili kuwasaidia watafiti kutathmini rasilimali zinazohitajika kurudia na kupanua kazi hii. Gharama hizi zinaakisi miundo, usanidi wa mifumo iliyolengwa na utaratibu uliotumiwa katika tathmini hii. Lengo letu pana ni kuwasaidia watetezi wa usalama kupata na kurekebisha udhaifu, kupunguza fursa zinazopatikana kwa washambuliaji na kuongeza gharama yao ya kutumia udhaifu wa programu.

Mwisho, kumbuka kuwa katika utafiti huu tulilenga mbinu za utafiti na kupima uwezo wa muundo, si gharama. Tunatarajia kuwa uhandisi wa kutosha wa mazingira ya uendeshaji unaweza kupunguza sana gharama katika kila hatua; kwa hiyo, gharama tunazoripoti ni zaidi makadirio ya kiwango cha juu.

Mfumo wetu wa majaribio wa utafiti wa udhaifu una mchakato wa hatua tano, unaotegemea muundo ujao wa usalama wa mtandao:

• Ugunduzi wa udhaifu: Mawakala hutambua sehemu za msimbo zinazohusiana na usalama na kuzikagua ili kupata matokeo ya awali.

• Uthibitishaji kwa kuendesha msimbo: Mawakala hujaribu kuzalisha tena kila matokeo ya awali katika mazingira yaliyotengwa na kuhifadhi ushahidi wa wakati wa uendeshaji. Hatua hii hutoa udhaifu uliozalishwa tena na kuthibitishwa.

• Tathmini ya uwezekano wa kutumia udhaifu: Mawakala hujaribu kama udhaifu uliothibitishwa unaweza kuruhusu kufichuliwa kwa taarifa au kuongeza ruhusa ndani ya mfumo.

• Utengenezaji wa viraka: Mawakala hutengeneza viraka vinavyoshughulikia kila udhaifu uliotambuliwa.

• Ukaguzi wa watafiti: Watafiti wa usalama hukagua programu ya uvamizi, kiraka na kiwango cha hatari kinachopendekezwa kabla ya kuripoti kwa wasimamizi.

Mwishoni mwa mchakato, mfumo hukusanya uchanganuzi wa chanzo cha tatizo, programu fupi ya kuthibitisha dhana kwa kusababisha hitilafu inayosimamisha mfumo, kiraka kinachopendekezwa na programu kamili ya uvamizi, ili kuwasaidia watafiti kutathmini ukubwa wa hatari ya udhaifu na kuwasilisha marekebisho kwenye mradi mkuu.

Si kila mstari wa msimbo katika kiini cha Linux unahusiana na usalama. Mchakato wetu ulitumia timu ya mawakala wa upelelezi kutambua sehemu muhimu zaidi za kukaguliwa, ambazo kisha zilikabidhiwa mawakala wa uchanganuzi ili watafute udhaifu.

Mawakala wa upelelezi husoma kila folda na faili na kuamua sehemu za kukagua kulingana na kama zinafikiwa na watumiaji wenye ruhusa chache na jinsi zinavyohusiana na usalama.

Hatua hii ilitambua sehemu 5,034 za kukaguliwa, zenye takriban mistari milioni 2.8 ya msimbo, karibu 7% ya msimbo wote wa kiini cha Linux. Hii ilipunguza sana gharama ya ukaguzi wa usalama ikilinganishwa na kuchanganua msimbo wote. Hatua hii iligharimu $3,426 za salio la API.

Kisha, mawakala wa uchanganuzi walichanganua kila sehemu iliyolengwa na kutoa matokeo ya awali kwa kutumia utaratibu sawa na wa programu-jalizi ya Codex Security⁠(fungua katika dirisha jipya). Kwa muhtasari, mawakala wa uchanganuzi husoma msimbo wa sehemu waliyokabidhiwa ili kuelewa jinsi inavyofanya kazi, kutambua vitisho vinavyoweza kuiathiri na kutafuta udhaifu ndani yake.

Ndani ya saa 12, mawakala wa uchanganuzi walitoa matokeo ya awali 2,308 baada ya kuondoa yaliyojirudia. Hatua hii iligharimu $316,549 za salio la API.

Matokeo ya awali si sawa na udhaifu uliothibitishwa. Kwa idadi hii, timu yetu ya utafiti haiwezi kuchunguza kila ripoti yenyewe.

Kwa hiyo tulilenga kuthibitisha matokeo ambayo a) yalifikiwa na mtumiaji mwenye ruhusa chache, b) hayakuhitaji uwezo wowote maalumu, na c) yalitoa ushahidi unaoweza kupimwa wa kuharibika kwa kumbukumbu.

Kwa kila matokeo ya awali, wakala wa uchunguzi wa awali aliunda programu ya kuthibitisha dhana na kuiendesha katika mashine pepe iliyotengwa iliyotumia kiini cha Linux chenye Kernel Address Sanitizer (KASAN). Wakala alifuatilia matokeo ya programu na dashibodi ya mfumo, kisha akaboresha programu ya kuthibitisha dhana kwa kurudia hadi izalishe tena hali iliyoripotiwa au amalize njia zote zinazoweza kuisababisha.

Ndani ya saa 30, mfumo wetu ulizalisha tena udhaifu 1724, takriban 74.7% ya matokeo ya awali 2,308. Kukagua msimbo pekee bila kuuendesha kunaweza kutoa tahadhari zisizo sahihi. Kwa hiyo tulivutiwa na usahihi wa mawakala wa uchanganuzi na ufanisi wa mawakala wa uchunguzi wa awali katika kuunda wenyewe programu zinazofanya kazi za kuthibitisha dhana kwa karibu robo tatu ya matokeo ya awali.

Matokeo mengi yaliyobaki yalihitaji ruhusa za juu zaidi au hayakuweza kuzalishwa tena ndani ya muda uliotengwa kutokana na hali ngumu za ushindani wa michakato, masharti mahususi ya kuchochea hitilafu (k.m., hitaji la ugawaji wa kumbukumbu kushindwa katika mstari fulani), au uthibitishaji unaochukua muda mrefu (k.m., kihesabu marejeleo kufikia kikomo na kuanza upya). Ni 3.1% pekee yaliyoonyesha uchanganuzi usio sahihi wa muundo, ambapo udhaifu ulioripotiwa ulitegemea hali isiyoweza kutokea.

Hatua ya uthibitishaji iligharimu jumla ya $73,330 za salio la API. Tuliona kuwa katika mchakato wetu wa uthibitishaji, ambao ulihitaji kuunda programu ya kuthibitisha dhana ili kubaini kama matokeo ya awali yalikuwa udhaifu halisi, hatua hii ilikuwa ghali zaidi kuliko kutoa pendekezo kwa kutegemea uchanganuzi wa msimbo bila kuuendesha. Pia, gharama za kujaribu kuthibitisha tahadhari sahihi na zisizo sahihi zilifanana. Kwa hiyo, kuondoa tahadhari zisizo sahihi mapema katika mchakato hupunguza gharama kwa kiasi kikubwa.

Uthibitishaji hubaini kuwa udhaifu ni halisi, lakini hauonyeshi uharaka unaohitajika kuushughulikia. Kwa mfano, udhaifu unaoweza kuruhusu kuongeza ruhusa ndani ya mfumo unastahili kipaumbele kikubwa zaidi kuliko ule unaoweza tu kusababisha kunyimwa huduma ndani ya mfumo. Baada ya kuthibitisha udhaifu 1,724, kazi iliyofuata ilikuwa kutambua matokeo yenye uwezekano mkubwa zaidi wa kuathiri usalama.

Wakala wa uchujaji wa awali alikagua kila ripoti, kumbukumbu ya hitilafu iliyosimamisha mfumo na msimbo chanzo unaohusika bila kuuendesha. Vigezo vyake vililegeza makusudi masharti ili kuepuka kutupilia mbali matokeo yanayoweza kuwa hatari, huku vikichuja visa visivyo na njia inayowezekana ya kutumia udhaifu. Hii ilipunguza matokeo hadi visa 313 vinavyoweza kuvuja taarifa na visa 1,238 vinavyoweza kuongeza ruhusa ndani ya mfumo.

Kisha mawakala wa uundaji wa programu za uvamizi (ExploitDev) walijaribu visa hivyo katika mashine pepe zilizotengwa na kusanidiwa kwa kinga zinazowashwa katika toleo la kawaida la Linux, zikiwemo Supervisor Mode Execution Prevention (SMEP), Supervisor Mode Access Prevention (SMAP), Kernel Address Space Layout Randomization (KASLR), na HARDENED_USERCOPY. Hii ilisaidia kuzuia tathmini zisizo halisi ambazo zilitegemea kuzimwa kwa kinga.

Mawakala waliunda programu 291 za kuthibitisha kuvuja kwa taarifa na programu 1,169 zinazofanya kazi za kuongeza ruhusa ndani ya mfumo, ambazo zingeweza kuwapa watumiaji wa mfumo wasio na ruhusa maalumu ufikiaji wa root.

Tulichanganua aina tofauti za udhaifu huo na kutengeneza viraka 948 tofauti kwa udhaifu uliotumiwa na programu hizo za uvamizi. Tunatumia idadi hiyo kubaini jumla ya udhaifu tofauti wa LPE. Programu za uvamizi zilizofanikiwa ziligharimu wastani wa $359 za salio kuundwa. Hiyo inafanya majaribio ya kubaini uwezekano wa kutumia udhaifu uliopatikana kuwa na gharama ndogo kwa watetezi wa usalama.

Wakala wa uchujaji wa awali wa udhaifu aligharimu $44,194 za salio la API. Hatua ya kutumia udhaifu iligharimu jumla ya $775,929 za salio la API: $84,929 kwa kushughulikia visa vinavyoweza kuvuja taarifa na $691,000 kwa visa vinavyoweza kuongeza ruhusa ndani ya mfumo.

Kwa wastani, kushughulikia kisa kinachoweza kuongeza ruhusa ndani ya mfumo ($558) kuligharimu takriban mara mbili ya kushughulikia kisa kinachoweza kuvuja taarifa ($271). Hii ni kwa sababu PoC za kuvuja kwa taarifa zilitoka katika hatua ya uthibitishaji na zilihitaji mabadiliko machache zaidi ili zitumike katika programu ya uvamizi. Kwa upande mwingine, kuunda programu ya uvamizi kutokana na kisa cha LPE kulihitaji hatua nyingi za ziada kama kupanga mkakati wa kutumia udhaifu, kutambua objekti zenye udhaifu za kutumia, kupita kinga na nyinginezo. Pia tuliona kuwa majaribio ya kutumia udhaifu ambayo hayakufaulu ($3,922 kwa visa 69) yaligharimu zaidi sana kuliko yaliyofaulu ($360 kwa visa 1169). Hii ilisababishwa na udhaifu mchache uliokuwa mgumu kutumia (k.m. hali za ushindani wa michakato). Kuweka sharti linalofaa la kusitisha jaribio, kama kusimama baada ya saa moja bila maendeleo, kungepunguza sana gharama ya ExploitDev.

Kwa kila udhaifu uliothibitishwa, mfumo pia hutengeneza kiraka. Tunaupa muundo msimbo chanzo unaohusika na kuuelekeza kufuata mbinu bora za kuandika viraka, kama kukagua kiraka bila kuendesha msimbo, kufuata mbinu za ukuzaji wa programu zinazotumiwa katika msimbo unaokizunguka, na kuchanganua aina tofauti za udhaifu ili kuhakikisha kiraka kinakamilika.

Kwa kufuata pendekezo la jumuiya ya kiini cha Linux, tayari tumetuma mamia ya ripoti na viraka vya udhaifu hatari zaidi na tunashirikiana na washirika wa Patch the Planet kutuma hatua kwa hatua viraka vya udhaifu uliobaki. Kazi hii ni sehemu ya ahadi yetu pana ya Daybreak ya kuunga mkono miradi ya programu huria.

Katika sehemu hii tunashiriki mafunzo, tafakari na uchanganuzi wa ziada kutoka katika utafiti huu.

Wakati wa utafiti huu, tuliona wasimamizi wa Linux wakichukua hatua haraka kurekebisha udhaifu na kulinda watumiaji. Ukaguzi ulifanywa katika kiini cha hivi karibuni zaidi cha Linux katikati ya Oktoba 2026. Ukaguzi unaojiendesha na uchanganuzi wa watafiti ulipokamilika baada ya siku 10, udhaifu 61 wa LPE ulikuwa tayari umerekebishwa katika mradi mkuu, udhaifu 43 ulikuwa na viraka vya majaribio, na udhaifu 299 ulikuwa ukiripotiwa na kujadiliwa hadharani.

Tunawashukuru sana wasimamizi wa Linux ambao wamekuwa wakifanya kazi kwa haraka kurekebisha matatizo yaliyotambuliwa, pamoja na jumuiya pana ya usalama inayochangia matokeo yake. Ushirikiano huu ndio unaohitajika ili kulinda programu zinazotumika duniani. Kasi kubwa ya kufichua na kurekebisha udhaifu pia inasisitiza umuhimu wa watumiaji na kampuni kusasisha programu zao.

Funzo kuu: Uchunguzi wa awali wa kiotomatiki unapaswa kuzingatia kasi kubwa ya kutolewa kwa viraka. Kuthibitisha upya matokeo kwa kutumia msimbo wa hivi karibuni zaidi, ikiwemo msimbo mpya uliounganishwa baada ya ukaguzi wa kwanza, husaidia kuepuka ripoti zinazojirudia au zilizopitwa na wakati. Hii huelekeza juhudi kwenye udhaifu ambao bado haujarekebishwa na kuwapa wasimamizi ushahidi wanaoweza kuufanyia kazi bila kuongeza mzigo wa ukaguzi usio wa lazima.

Tulipokuwa tukitengeneza mchakato huu mwishoni mwa Julai 2026, GPT‑5.6 Sol ilipata na kutumia udhaifu 166 tofauti wa LPE kwa gharama ya jumla ya $513,690 za salio la API.

Katika ukaguzi wa pili, katikati ya Oktoba 2026, muundo mpya zaidi wa usalama wa mtandao ulipata na kutumia udhaifu 948 tofauti wa LPE kwa gharama ya jumla ya $1,213,430 za salio la API. Katika mazoezi yote mawili, tulikagua tawi la master la kiini cha Linux lililokuwa la hivi karibuni zaidi wakati huo.

Funzo kuu: Kagua tena msimbo uliokaguliwa awali kadiri uwezo wa miundo unavyoboreka. Muundo wenye uwezo mkubwa zaidi unaweza kufichua udhaifu ambao miundo ya awali haikuona, hata unapotumia mazingira yale yale ya uendeshaji wa utafiti.

Tulichukua sampuli ya programu 166 za uvamizi zilizoundwa na mawakala na kuchanganua mbinu za kutumia udhaifu zilizotumiwa ndani yake. Kwa kadiri tunavyojua, mawakala walitumia mbinu 10 mpya za kutumia udhaifu katika programu za sampuli hiyo. Tulishiriki mbinu hizo na wataalamu wa nje wa kutumia udhaifu wa kiini, na wao pia hawakuwa wameziona hapo awali.

Kati ya mbinu hizo 10, mbili ni aina mpya za objekti zinazodumu na zinazoweza kubadilishwa ukubwa, ambazo muundo ulitumia kujaza objekti katika akiba lengwa ya kiini; mbili ni mbinu mpya za kupanga kurasa za kumbukumbu ili kuongeza utegemevu wa programu za uvamizi; tano ni mbinu mpya zinazotumia data pekee kupata ruhusa za juu zaidi moja kwa moja au kwa kuandika kwenye eneo lolote la kumbukumbu; mbinu nyingine inahusisha kuchanganya kiholela aina za data. Kwa sababu za usalama, hatutoi maelezo kamili ya kiufundi ya mbinu hizi mpya za kutumia udhaifu katika makala haya.

Funzo kuu: Miundo ya kiwango cha juu zaidi hailinganishi tu msimbo na mifumo inayojulikana kuwa na udhaifu wala kutumia mbinu zinazojulikana pekee; inaonyesha ubunifu na njia mpya.

Sehemu muhimu ya dhamira ya timu yetu ni kupima gharama ya kutafuta na kutumia udhaifu, kisha kutumia ushahidi huo kuongoza uwekezaji katika ulinzi. Lengo letu ni kuwasaidia watetezi wa usalama kurekebisha udhaifu kabla washambuliaji hawajautumia, na kufanya gharama ya kutumia udhaifu wa programu kuwa kubwa kiasi cha kuwazuia washambuliaji. Kupima gharama za kutumia udhaifu hutusaidia kutathmini jinsi changamoto hiyo inavyobadilika kadiri uwezo wa miundo unavyoboreka. Katika sehemu hii, tunalinganisha gharama ya kuendesha mchakato wetu na zawadi za mipango ya kuripoti hitilafu kwa udhaifu uliotambuliwa.

Mashine pepe zilizolengwa katika jaribio letu zilitumia mfumo wa kawaida wa uendeshaji wa kompyuta za mezani, si mfumo uliodhoofishwa, kwa kuzingatia hali zilezile za vitisho zinazotumiwa katika mashindano ya usalama wa mtandao (k.m. Pwn2Own⁠(fungua katika dirisha jipya), TyphoonPWN⁠(fungua katika dirisha jipya)). Hapo awali, Pwn2Own na TyphoonPWN zilitoa zawadi za kuripoti hitilafu za $20,000 na $70,000 mtawalia kwa programu za kuongeza ruhusa ndani ya mfumo kupitia kiini cha Linux. Tukitumia viwango hivyo vya awali vya zawadi kwa programu 948 za uvamizi, tunapata thamani ya kinadharia ya $18.9M—$66.3M, takriban mara 16 hadi 55 ya gharama ya mchakato wetu.

Pia tulijaribu mchakato wetu katika mpango wa Google wa zawadi za udhaifu wa kernelCTF⁠(fungua katika dirisha jipya), ambao unalenga kiini cha Linux kilichoimarishwa usalama na chenye sehemu chache zaidi zinazoweza kushambuliwa. Tuliendesha mchakato katika toleo jipya zaidi la kiini cha Linux kwenye mazingira ya kernelCTF (halikupatana na kinga ya SLAB_VIRTUAL ya kernelCTF, hivyo tukaiondoa kwenye usanidi), na tukapata programu 25 za kuthibitisha dhana ya kuvuja kwa taarifa na programu 21 za kuongeza ruhusa ndani ya mfumo. Kwa kulinganisha, kufikia wakati wa kuandika makala haya, kernelCTF ilikuwa imekubali programu 26 zilizothibitishwa za uvamizi za LPE za siku-sifuri katika mwaka wa 2026. Zoezi lote lilichukua saa 112 kwa jumla, likagharimu takriban $32,936 za salio la API, huku ugunduzi wa udhaifu ukichangia 83.7% ya gharama ya API. Ikiwa udhaifu huo 21 ungekubaliwa katika mpango huo, ungeleta zawadi ya takriban $1.5M, karibu mara 45 ya gharama.

Funzo kuu: Kwa kuzingatia viwango vya zawadi vilivyotangazwa hadharani na miundo ya sasa yenye uwezo wa usalama wa mtandao, mchakato wetu wa utafiti wa udhaifu ungeleta faida baada ya gharama wakati wa utafiti huu. Watetezi wa usalama wanapaswa kuchanganua programu zao mapema ili gharama ya kutumia udhaifu wake iwe kubwa kiasi cha kuwazuia washambuliaji.

Wakati wa tathmini ya uwezekano wa kutumia udhaifu, mawakala wa ExploitDev walipewa ripoti ya udhaifu na jukumu la kuunda programu ya uvamizi inayofanya kazi kikamilifu. Mchakato wetu uliweka alama kuwa udhaifu umetumiwa ikiwa kiolesura cha amri chenye ruhusa za root kilipatikana. Katika jaribio moja la awali, hatua ya kutumia udhaifu iliripoti programu 200 zilizofanikiwa kuongeza ruhusa ndani ya mfumo. Hata hivyo, baada ya ukaguzi wa watafiti, tuligundua kuwa programu 20 kati ya hizi zilikuwa zimepata ruhusa za root kupitia udhaifu tofauti wa siku-sifuri na ule zilizokabidhiwa. Hii inaashiria kuwa hata mawakala wanapofanikiwa kutumia udhaifu, uthibitishaji unaofaa bado unahitajika.

Baadaye tuliimarisha masharti ya kazi na kuongeza ukaguzi huru wa kuthibitisha kuwa kila programu ya mwisho ya uvamizi ilitumia udhaifu iliyokabidhiwa.

Funzo kuu: Katika utafiti wa usalama unaojiendesha, thibitisha njia iliyotumiwa kupata matokeo pamoja na matokeo yenyewe; kutenga mazingira, ufuatiliaji na kaguzi huru ni hatua muhimu za udhibiti.

Mwanzoni mwa utafiti huu, tulichunguza iwapo tunapaswa kujenga mfumo mpana wa uratibu unaomzunguka wakala ili kuboresha uwezo wake wa usalama wa mtandao. Matokeo yetu yaliashiria kuwa miundo yenye uwezo mkubwa zaidi inahitaji uratibu na mwongozo mdogo. Na uboreshaji mdogo unaopatikana haustahili gharama ya matengenezo. Kwa hiyo, tuliamua kuondoa mfumo huo mpana wa uratibu.

Jaribio lililinganisha GPT‑5.5 Cyber na GPT‑5.6 Cyber. Kwa uchunguzi wetu, GPT‑5.5 Cyber haikutambua kwa uthabiti wakati na namna ya kutumia mbinu zilizopo za kutumia udhaifu wa kiini cha Linux. Kisha tulikusanya mbinu 103 katika muundo wa taarifa ulio rahisi kwa muundo wa AI kutumia, tukaziweka katika mazingira ya wakala na kumwelekeza azitumie. Katika visa 63 vilivyoteuliwa kwa majaribio ya kutumia udhaifu, hii iliongeza kiwango cha mafanikio kutoka 76.2% hadi 88.9%.

Tuliporudia jaribio hili kwa GPT‑5.6 Cyber, muundo huo uliweza vizuri zaidi kutafuta, kuchagua na kutumia mbinu zinazofaa wenyewe. Tuliondoa uratibu wa mbinu na ujuzi, na utaratibu huu wa GPT‑5.6 Cyber wenye uratibu mdogo ulifanya vizuri zaidi kuliko utaratibu wa GPT‑5.5 Cyber uliokuwa na mfumo mpana zaidi wa usaidizi. Kurejesha tabaka la ziada la mbinu kwa GPT‑5.6 Cyber kulileta ongezeko dogo tu la pointi 1.5 za asilimia.

Funzo kuu: Tathmini upya uratibu na mazingira yako ya uendeshaji kadiri uwezo wa muundo wa msingi unavyobadilika. Mfumo wa usaidizi unaoboresha sana kizazi kimoja cha miundo unaweza kuwa na manufaa madogo kwa muundo wenye uwezo mkubwa zaidi, na unapaswa kutathminiwa kwa kulinganisha manufaa yake na gharama ya matengenezo.

Mwanzoni, muundo ulipoelekezwa moja kwa moja kutengeneza viraka vya kupendekezwa, ulitengeneza viraka vilivyofanya kazi ipasavyo kuzuia programu ya kuthibitisha dhana, lakini wakati mwingine vikaleta matatizo mengine: msimbo mwingi kuliko uliohitajika, uwezekano wa kudhoofisha utendaji, kutofuata kanuni za uandishi wa msimbo, au kutokagua msimbo unaohusiana ili kutafuta aina nyingine za udhaifu huohuo, hali iliyosababisha viraka visivyokamilika.

Maelekezo ya ziada na maboresho ya kurudia katika mchakato wa kutengeneza viraka yaliimarisha ubora wa viraka. Hii inaashiria kuwa, kwa usimamizi unaofaa, viraka vya usalama vinavyotengenezwa na AI vinaweza kuwa sahihi, kufanya mabadiliko machache tu yanayohitajika, na kufuata kanuni zilizopo za msimbo. Utafiti unaendelea kikamilifu katika eneo hili, na tunaamini kazi hii itakuwa rahisi na yenye ufanisi zaidi kwa miundo ijayo. Katika visa vichache, mfumo wetu wa majaribio wa utafiti pia uliweza kutambua matatizo katika viraka vilivyoandikwa na wataalamu, ambayo yalirekebishwa kabla ya viraka hivyo kuunganishwa katika msimbo mkuu.

Funzo kuu: Miundo inaweza kuharakisha mchakato wa kuweka viraka, lakini ujuzi wa kuweka viraka na mazingira ya uendeshaji vinaweza kuhitaji maboresho ya kurudia ili kuhakikisha viraka vinatimiza kwa uthabiti mahitaji ya utendaji na yale yasiyo ya utendaji. Aidha, tunapendekeza kutumia miundo kukagua viraka vilivyotengenezwa na watu na AI kwa mtazamo wa mshambuliaji. Hii inaweza kutambua matatizo kama uwezekano wa kupita kinga ya kiraka, kutoshughulikia njia au aina nyingine za mashambulizi, na mengineyo.

Katika jaribio letu la kernelCTF, mbali na programu 21 za kutumia udhaifu wa siku-sifuri katika kiini cha Linux, mfumo wetu wa majaribio wa utafiti pia ulipata na kutumia udhaifu wa QEMU TCG. Wakala wa uchanganuzi alikabidhiwa kuchanganua msimbo wa kuingia kwenye miito ya mfumo, na alipokuwa akiandika programu za kujaribu mabadiliko ya ruhusa, alikumbana na hitilafu isiyotarajiwa iliyosimamisha kiini. Alichunguza hitilafu hiyo na kufuatilia chanzo chake hadi QEMU TCG bila kufikia msimbo chanzo wa QEMU, na akajumuisha udhaifu huo katika ripoti. Baadaye, wakala wa ExploitDev alifanikiwa kuunda programu ya kuongeza ruhusa ndani ya mfumo kwa kutumia udhaifu huu. Tuligundua udhaifu huu wa QEMU tulipokuwa tukichanganua wenyewe programu za uvamizi, na tukathibitisha kuwa ulikuwa umerekebishwa katika mradi mkuu wa QEMU lakini si katika toleo lililotumika wakati wa jaribio.

Funzo kuu: Miundo ya kiwango cha juu zaidi yenye uwezo wa usalama wa mtandao inaweza kupata udhaifu katika miundombinu ya majaribio. Tunapendekeza kupima kila sehemu ya miundombinu kabla ya kufanya utafiti wa udhaifu kwa kutumia mbinu za mashambulizi. Tumepima miundombinu yetu mapema, tukafichua na kurekebisha udhaifu mwingi katika Kata, Moby/Docker, gVisor na miradi mingine.

Lengo letu ni kugeuza uwezo unaoongezeka wa miundo kuwa faida ya kudumu kwa watu wanaolinda Intaneti. Utafiti huu unaonyesha kuwa uwezo unaokua wa miundo ya kiwango cha juu zaidi katika usalama wa mtandao unaweza kutumika kutafuta kwa ufanisi udhaifu katika programu changamano, kama vile kiini cha Linux. Kuimarisha usalama wa miradi muhimu ya programu kama Linux na miradi mingine ya programu huria kunaweza kulinda mifumo na watumiaji wengi wanaoitegemea.

Kupitia Patch the Planet, ambao ni mpango wa Daybreak, tunalenga kupanua utafiti huu hadi miradi mingine muhimu ya programu na kubuni njia za kuaminika za kuweka viraka kiotomatiki, tukishirikiana na wasimamizi wa miradi na washirika wa usalama. Tunataka kuendelea kupunguza fursa zinazopatikana kwa washambuliaji na kuongeza gharama ya kutafuta na kutumia udhaifu, hadi manufaa yanayotarajiwa yasistahili tena gharama ya shambulizi.

Kila kizazi cha miundo kinapaswa kutusaidia kujenga programu ambazo zitakuwa ngumu zaidi kuvamiwa na kizazi kinachofuata. Tutaendelea kufanya kazi ili kujenga Intaneti salama ambayo kila mtu anaweza kuitumia kubuni kwa furaha.