रूट एक्सेस हासिल करने के एक हज़ार कम रास्ते

सिक्योरिटी रिसर्च में पहले हर कमज़ोरी की अलग से लंबे समय तक जाँच करनी पड़ती थी. अब इस रिसर्च को ज़्यादा-से-ज़्यादा एक व्यवस्थित प्रोसेस के तौर पर किया जा सकता है. इस डॉक्यूमेंट में हमने इस दिशा में अपनी एक कोशिश के बारे में बताया है.

बड़े पैमाने पर कमज़ोरियाँ ढूँढना आसान होता जा रहा है, लेकिन उनकी प्रायोरिटी तय करना और वैलिडेशन करना अब भी ऐसे स्टेप्स हैं, जिनकी वजह से काम धीमा पड़ता है. हमने एक ऐसे रिसर्च एनवायरनमेंट में Linux कर्नेल की सिक्योरिटी कमज़ोरियाँ ढूँढने के लिए प्रोटोटाइप बनाया, जहाँ टेस्टिंग के हालात हमारे कंट्रोल में थे. हमारे प्रोटोटाइप ने Linux कर्नेल में 2,308 संभावित कमज़ोरियों की पहचान करके उनका एनालिसिस किया और 1,724 कमज़ोरियों को डायनैमिक तरीके से दोबारा पैदा किया. साथ ही, इसने लोकल प्रिविलेज एस्केलेशन (LPE) के 948 एक्सप्लॉइट तैयार किए, जिनकी मदद से बिना प्रिविलेज वाला कोई लोकल यूज़र रूट एक्सेस हासिल कर सकता था.

हमने इन सबूतों के आधार पर तय किया कि किन कमज़ोरियों की रिपोर्ट पहले करनी है. साथ ही, मेंटेनर्स के रिव्यू के लिए संभावित पैच भी तैयार किए. Linux कर्नेल कम्युनिटी की गाइडेंस के मुताबिक, हमने सबसे गंभीर कमज़ोरियों से शुरुआत की. अब हम Patch the Planet के पार्टनर्स के साथ मिलकर बाकी रिपोर्ट्स और पैच पर काम कर रहे हैं.

जून में हमने अपनी Patch the Planet पहल के तहत बताया था कि GPT‑5.5 Cyber ने Linux कर्नेल में कमज़ोरियाँ खोजी थीं और उनका वैलिडेशन करके रिपोर्ट करने के लिए 24 लोकल प्रिविलेज एस्केलेशन एक्सप्लॉइट डेवलप किए थे. हमने इस काम को आगे बढ़ाकर एक पाइपलाइन बनाई, जिसमें आने वाले एक साइबर मॉडल का इस्तेमाल किया गया. इस पाइपलाइन में कमज़ोरियाँ ढूँढना, डायनैमिक वैलिडेशन, एक्सप्लॉइटेबिलिटी असेसमेंट और पैच जेनरेशन शामिल थे. पाइपलाइन का काम पूरा होने पर ह्यूमन रिसर्चर्स ने आउटपुट्स का रिव्यू किया और मिली कमज़ोरियों की रिपोर्ट उनके पैच के साथ दी.

Linux कर्नेल, Android डिवाइसेज़, क्लाउड इंफ़्रास्ट्रक्चर, सुपरकंप्यूटर्स और ऐसे दूसरे सिस्टम्स का अहम हिस्सा है, जिन्हें अरबों लोग इस्तेमाल करते हैं. कर्नेल में 4 करोड़ से ज़्यादा लाइनों का कोड है. सिस्टम कॉल्स, नेटवर्किंग, फ़ाइल सिस्टम्स और डिवाइस ड्राइवर्स की वजह से इसमें अटैक के कई संभावित रास्ते मौजूद हैं. हमने Linux को इसलिए चुना, ताकि यह जाँच सकें कि इतने बड़े और अहम कोडबेस में फ़्रंटियर मॉडल्स कितने असरदार तरीके से कमज़ोरियाँ ढूँढ सकते हैं और सिक्योरिटी पर उनके असर को दिखा सकते हैं.

शुरुआती वल्नरेबिलिटी डिस्कवरी स्टेज में हज़ारों संभावित कमज़ोरियाँ मिलीं. इनकी संख्या इतनी ज़्यादा थी कि सिक्योरिटी रिसर्चर्स के लिए हर एक का मैन्युअल रिव्यू और ट्रायेज करना मुश्किल था. हमारी वल्नरेबिलिटी डिस्कवरी पाइपलाइन के सामने असली चैलेंज कमज़ोरियाँ ढूँढना नहीं था. बल्कि यह तय करना था कि किन कमज़ोरियों को दोबारा सामने लाया जा सकता है, वे किन सिक्योरिटी सीमाओं को पार करती हैं और किन पर मेंटेनर्स को सबसे पहले ध्यान देना चाहिए.

OpenAI की साइबर टीम का मिशन उन सॉफ़्टवेयर को सुरक्षित बनाने में मदद करना है, जिन पर दुनिया निर्भर करती है. हम हर स्टेज का API खर्च शेयर करते हैं, ताकि रिसर्चर्स यह समझ सकें कि इस काम को दोहराने और आगे बढ़ाने के लिए कितने रिसोर्सेज़ की ज़रूरत होगी. ये खर्च इस इवैल्यूएशन में इस्तेमाल किए गए मॉडल्स, टारगेट कॉन्फ़िगरेशन्स और वर्कफ़्लो पर आधारित हैं. हमारा बड़ा लक्ष्य डिफ़ेंडर्स को कमज़ोरियाँ ढूँढने और ठीक करने में मदद करना है, ताकि अटैकर्स के पास कम मौके हों और सॉफ़्टवेयर की कमज़ोरियों का फ़ायदा उठाना उनके लिए ज़्यादा महँगा हो जाए.

आखिर में, ध्यान दें कि इस रिसर्च में हमारा फ़ोकस खर्च पर नहीं, बल्कि रिसर्च के तरीके और मॉडल की क्षमताएँ मापने पर था. हमें उम्मीद है कि हार्नेस इंजीनियरिंग को अच्छी तरह बेहतर बनाकर हर स्टेज का खर्च काफ़ी कम किया जा सकता है. इसलिए हमने जो खर्च रिपोर्ट किए हैं, उन्हें खर्च की ऊपरी सीमा के तौर पर देखना ज़्यादा सही होगा.

हमारा वल्नरेबिलिटी रिसर्च प्रोटोटाइप पाँच स्टेज वाली एक पाइपलाइन है, जिसके मुख्य हिस्से में जल्द आने वाला एक साइबर मॉडल इस्तेमाल होता है:

• वल्नरेबिलिटी डिस्कवरी: एजेंट्स कोडबेस के उन हिस्सों की पहचान करते हैं जो सिक्योरिटी के लिहाज़ से अहम हैं और संभावित कमज़ोरियाँ ढूँढने के लिए उन्हें स्कैन करते हैं.

• डायनैमिक वैलिडेशन: एजेंट्स हर संभावित कमज़ोरी को एक अलग-थलग एनवायरनमेंट में दोबारा सामने लाने की कोशिश करते हैं और रनटाइम से मिले सबूतों को सेव करते हैं. इस स्टेप के बाद उन कमज़ोरियों की लिस्ट मिलती है, जिन्हें दोबारा सामने लाकर वैलिडेट किया जा चुका है.

• एक्सप्लॉइटेबिलिटी असेसमेंट: एजेंट्स टेस्ट करते हैं कि क्या वैलिडेट की गई कमज़ोरियों की वजह से जानकारी लीक हो सकती है या लोकल प्रिविलेज एस्केलेशन हो सकता है.

• पैच जेनरेशन: एजेंट्स हर पहचानी गई कमज़ोरी को ठीक करने के लिए पैच जनरेट करते हैं.

• इंसानों से रिव्यू: मेंटेनर्स को रिपोर्ट करने से पहले सिक्योरिटी रिसर्चर्स एक्सप्लॉइट, पैच और कमज़ोरी की गंभीरता के प्रस्तावित लेवल का रिव्यू करते हैं.

पाइपलाइन के आखिर में सिस्टम रूट कॉज़ एनालिसिस, क्रैश पैदा करने वाला एक मिनिमल प्रूफ़ ऑफ़ कॉन्सेप्ट, एक संभावित पैच और एक पूरा एक्सप्लॉइट एक साथ तैयार करता है. इससे ह्यूमन रिसर्चर्स को कमज़ोरी की गंभीरता का आकलन करने और उसके फ़िक्स अपस्ट्रीम प्रोजेक्ट में शामिल करवाने में मदद मिलती है.

Linux कर्नेल में कोड की हर लाइन सिक्योरिटी के लिहाज़ से अहम नहीं होती. हमारी पाइपलाइन ने Scout एजेंट्स की एक टीम का इस्तेमाल करके ऐसे ऑडिट टारगेट्स की पहचान की, जिनकी जाँच करना सबसे ज़्यादा फ़ायदेमंद था. इसके बाद, इन टारगेट्स को कमज़ोरियाँ ढूँढने के लिए Analyst एजेंट्स को दिया गया.

Scout एजेंट्स हर फ़ोल्डर और फ़ाइल को पढ़ते हैं. फिर यह देखते हुए ऑडिट के लिए टारगेट्स चुनते हैं कि कम प्रिविलेज वाले यूज़र्स उन तक पहुँच सकते हैं या नहीं और वे सिक्योरिटी के लिहाज़ से कितने अहम हैं.

इस स्टेप में 5,034 ऑडिट टारगेट्स की पहचान हुई, जिनमें लगभग 28 लाख लाइन्स का कोड था. यह पूरे Linux कर्नेल कोडबेस का लगभग 7% है. इससे पूरे कोडबेस का एनालिसिस करने के मुकाबले सिक्योरिटी ऑडिट की लागत काफ़ी कम हो गई. इस स्टेप में API क्रेडिट्स के रूप में $3,426 खर्च हुए.

इसके बाद, एनालिस्ट एजेंट्स ने Codex Security प्लगइन⁠(एक नई विंडो में खुलेगा) जैसे वर्कफ़्लो का इस्तेमाल करके हर ऑडिट टारगेट का एनालिसिस किया और संभावित कमज़ोरियों की पहचान की. मोटे तौर पर, एनालिस्ट एजेंट्स अपने असाइन किए गए ऑडिट टारगेट का कोड पढ़ते हैं, ताकि समझ सकें कि वह कैसे काम करता है. फिर वे उसके थ्रेट मॉडल की पहचान करते हैं और उसमें कमज़ोरियाँ ढूँढते हैं.

एनालिस्ट एजेंट्स ने 12 घंटे के अंदर डुप्लिकेट्स हटाने के बाद 2,308 संभावित कमज़ोरियों की रिपोर्ट तैयार की. इस स्टेप में API क्रेडिट्स के तौर पर $3,16,549 खर्च हुए.

किसी संभावित कमज़ोरी की पहचान होने का मतलब यह नहीं है कि उसकी जाँच पूरी हो चुकी है और वह कमज़ोरी मौजूद है. इतने बड़े पैमाने पर हर रिपोर्ट की मैन्युअल जाँच करना हमारी रिसर्च टीम के लिए संभव नहीं है.

इसलिए हमने ऐसी संभावित कमज़ोरियों के वैलिडेशन पर फ़ोकस किया, जिनमें a) कम प्रिविलेज वाले यूज़र्स पहुँच सकते थे, b) किसी खास क्षमता की ज़रूरत नहीं थी और c) मेमोरी करप्शन के ऐसे सबूत मिलते थे, जिन्हें मापा जा सकता था.

हर संभावित कमज़ोरी के लिए एक ट्रायेज एजेंट ने प्रूफ़-ऑफ़-कॉन्सेप्ट तैयार किया और उसे एक अलग रखी गई वर्चुअल मशीन में चलाया. इस मशीन पर Kernel Address Sanitizer (KASAN) के साथ Linux कर्नेल चल रहा था. एजेंट ने प्रोग्राम के आउटपुट और सिस्टम कंसोल, दोनों पर नज़र रखी. फिर प्रूफ़-ऑफ़-कॉन्सेप्ट में बार-बार सुधार किया, जब तक कि रिपोर्ट किया गया व्यवहार दोबारा सामने नहीं आ गया या उसे ट्रिगर करने के सभी संभावित तरीके आज़माए नहीं जा चुके थे.

हमारे सिस्टम ने 30 घंटे के अंदर 1,724 कमज़ोरियों को दोबारा पैदा किया. यह 2,308 संभावित कमज़ोरियों का लगभग 74.7% था. सिर्फ़ स्टैटिक कोड रिव्यू करने पर ऐसी कमज़ोरियाँ भी सामने आ सकती हैं, जो असल में मौजूद नहीं हैं. इसलिए एनालिस्ट एजेंट्स की सही कमज़ोरियाँ पहचानने की क्षमता और ट्रायेज एजेंट्स का परफ़ॉर्मेंस हमारे लिए काफ़ी अच्छा था. ट्रायेज एजेंट्स ने लगभग तीन-चौथाई संभावित कमज़ोरियों के लिए अपने आप काम करने वाले प्रूफ़-ऑफ़-कॉन्सेप्ट तैयार किए.

बाकी बची ज़्यादातर संभावित कमज़ोरियों के लिए या तो ज़्यादा प्रिविलेज की ज़रूरत थी या उन्हें तय समय में दोबारा पैदा नहीं किया जा सका. इसकी वजह मुश्किल रेस कंडीशन्स, खास ट्रिगर कंडीशन्स (जैसे कोड की किसी खास लाइन पर मेमोरी एलोकेशन का फ़ेल होना ज़रूरी होना) या ज़्यादा समय लेने वाला वैलिडेशन (जैसे रेफ़काउंट रैपअराउंड) था. सिर्फ़ 3.1% मामलों में मॉडल का एनालिसिस गलत था, क्योंकि रिपोर्ट की गई कमज़ोरी ऐसी कंडीशन पर आधारित थी जिसका होना संभव ही नहीं था.

वैलिडेशन स्टेप में API क्रेडिट्स के तौर पर कुल $73,330 खर्च हुए. हमने देखा कि हमारी वैलिडेशन पाइपलाइन में किसी संभावित कमज़ोरी के सच में मौजूद होने की जाँच के लिए प्रूफ़-ऑफ़-कॉन्सेप्ट बनाना ज़रूरी था. यह प्रोसेस सिर्फ़ स्टैटिक एनालिसिस के आधार पर सुझाव देने के मुकाबले ज़्यादा महँगा था. साथ ही, सही कमज़ोरी और गलत तरीके से पहचानी गई कमज़ोरी, दोनों का वैलिडेशन करने की कोशिश में लगभग एक जैसा खर्च आया. इसलिए पाइपलाइन के शुरुआती स्टेप्स में ही फ़ॉल्स पॉज़िटिव्स हटाने से पूरे प्रोसेस की लागत काफ़ी कम हो सकती है.

वैलिडेशन से यह पता चलता है कि कोई कमज़ोरी सच में मौजूद है, लेकिन इससे यह तय नहीं होता कि उसे कितनी जल्दी ठीक करना चाहिए. उदाहरण के लिए, जिस कमज़ोरी से लोकल प्रिविलेज एस्केलेशन हो सकता है, उसे उस कमज़ोरी से ज़्यादा प्रायोरिटी मिलनी चाहिए, जो सिर्फ़ लोकल डिनायल ऑफ़ सर्विस का कारण बन सकती है. 1,724 कमज़ोरियों को वैलिडेट करने के बाद अगला टास्क उन कमज़ोरियों की पहचान करना था, जिनका सिक्योरिटी पर सबसे ज़्यादा असर पड़ सकता था.

शुरुआती स्क्रीनिंग एजेंट ने हर रिपोर्ट, क्रैश लॉग और उससे जुड़े सोर्स कोड का स्टैटिक एनालिसिस किया. इसे जान-बूझकर इस तरह सेट किया गया था कि संभावित गंभीर कमज़ोरियाँ छूटें नहीं, लेकिन ऐसे मामले हट जाएँ जिनमें एक्सप्लॉइट करने का कोई संभावित रास्ता न हो. इससे कैंडिडेट्स की संख्या घटकर 313 इन्फ़ॉर्मेशन लीक और 1,238 लोकल प्रिविलेज एस्केलेशन कैंडिडेट्स रह गई.

इसके बाद एक्सप्लॉइट डेवलपमेंट (ExploitDev) एजेंट्स ने इन कैंडिडेट्स को अलग-थलग वर्चुअल मशीनों में टेस्ट किया. इन मशीनों में स्टैंडर्ड Linux डिस्ट्रिब्यूशन की सिक्योरिटी प्रोटेक्शन्स चालू थीं, जिनमें सुपरवाइज़र मोड एग्ज़ीक्यूशन प्रिवेंशन (SMEP), सुपरवाइज़र मोड एक्सेस प्रिवेंशन (SMAP), कर्नेल एड्रेस स्पेस लेआउट रैन्डमाइज़ेशन (KASLR) और HARDENED_USERCOPY शामिल थे. इससे ऐसे असेसमेंट से बचने में मदद मिली, जो सिर्फ़ सिक्योरिटी प्रोटेक्शन्स बंद होने पर ही सही साबित होते.

एजेंट्स ने इन्फ़ॉर्मेशन लीक के लिए 291 प्रूफ़ ऑफ़ कॉन्सेप्ट और 1,169 काम करने वाले लोकल प्रिविलेज एस्केलेशन एक्सप्लॉइट्स तैयार किए. इन एक्सप्लॉइट्स की मदद से बिना विशेष प्रिविलेज वाले लोकल यूज़र्स को रूट एक्सेस मिल सकता था.

हमने वैरिएंट एनालिसिस किया और इन एक्सप्लॉइट्स से जुड़ी कमज़ोरियों के लिए 948 अलग-अलग पैच तैयार किए. इसी संख्या के आधार पर हमने यूनिक LPE की कुल संख्या तय की. सफल एक्सप्लॉइट तैयार करने में औसतन $359 के क्रेडिट्स खर्च हुए. इसका मतलब है कि डिफ़ेंडर्स के लिए ढूँढी गई कमज़ोरियों की एक्सप्लॉइटेबिलिटी टेस्ट करना तुलनात्मक रूप से कम खर्चीला है.

शुरुआती वल्नरेबिलिटी स्क्रीनिंग एजेंट पर $44,194 के API क्रेडिट्स खर्च हुए. एक्सप्लॉइटेशन स्टेज में कुल $775,929 के API क्रेडिट्स खर्च हुए. इनमें से $84,929 इन्फ़ॉर्मेशन लीक कैंडिडेट्स को प्रोसेस करने और $691,000 लोकल प्रिविलेज एस्केलेशन कैंडिडेट्स को प्रोसेस करने पर खर्च हुए.

औसतन, एक लोकल प्रिविलेज एस्केलेशन कैंडिडेट को प्रोसेस करने का खर्च ($558), एक इन्फ़ॉर्मेशन लीक कैंडिडेट ($271) के मुकाबले लगभग दोगुना था. इसकी वजह यह थी कि इन्फ़ॉर्मेशन लीक के PoC वैलिडेशन स्टेज से ही उपलब्ध थे और उन्हें एक्सप्लॉइट में इस्तेमाल करने लायक बनाने के लिए कम बदलाव करने पड़ते थे. दूसरी ओर, LPE कैंडिडेट से एक्सप्लॉइट बनाने के लिए कई अतिरिक्त स्टेप्स की ज़रूरत थी. इनमें एक्सप्लॉइटेशन की प्लानिंग, इस्तेमाल किए जा सकने वाले कमज़ोर ऑब्जेक्ट्स की पहचान और सिक्योरिटी मिटिगेशन्स को बायपास करना शामिल था. हमने यह भी देखा कि असफल एक्सप्लॉइटेशन कोशिशों का खर्च (69 मामलों में $3,922) सफल कोशिशों (1,169 मामलों में $360) से काफ़ी ज़्यादा था. इसकी वजह कुछ ऐसी कमज़ोरियाँ थीं, जिन्हें एक्सप्लॉइट करना मुश्किल था, जैसे रेस कंडीशन्स. अगर कोशिश रोकने की कोई सही शर्त तय की जाती, जैसे एक घंटे तक कोई प्रोग्रेस न होने पर कोशिश बंद कर देना, तो ExploitDev का खर्च काफ़ी कम हो सकता था.

हर वैलिडेट की गई कमज़ोरी के लिए सिस्टम एक पैच भी जनरेट करता है. हम मॉडल को उससे जुड़ा सोर्स कोड देते हैं और पैच लिखने की बेस्ट प्रैक्टिसेज़ फ़ॉलो करने के निर्देश देते हैं. इनमें पैच पर स्टैटिक चेक करना, आसपास के कोड में इस्तेमाल होने वाली सॉफ़्टवेयर डेवलपमेंट प्रैक्टिसेज़ को फ़ॉलो करना और वैरिएंट एनालिसिस करना शामिल है, ताकि यह पक्का हो सके कि पैच पूरी तरह समस्या को ठीक करता है.

Linux कर्नेल कम्युनिटी के सुझाव पर हमने गंभीर कमज़ोरियों के लिए सैकड़ों रिपोर्ट्स और पैच पहले ही भेज दिए हैं. बाकी कमज़ोरियों के पैच धीरे-धीरे भेजने के लिए हम Patch the Planet पार्टनर्स के साथ काम कर रहे हैं. यह काम ओपन-सोर्स प्रोजेक्ट्स को सपोर्ट करने की हमारी बड़ी Daybreak प्रतिबद्धता का हिस्सा है.

इस सेक्शन में हम इस रिसर्च से मिली सीख, अपने अनुभव और अतिरिक्त एनालिसिस शेयर कर रहे हैं.

इस रिसर्च के दौरान हमने देखा कि Linux के मेंटेनर्स कमज़ोरियों को ठीक करने और यूज़र्स को सुरक्षित रखने के लिए तेज़ी से काम कर रहे थे. अक्टूबर 2026 के बीच में Linux कर्नेल के सबसे नए वर्ज़न पर स्कैन किया गया था. जब 10 दिनों बाद ऑटोनॉमस स्कैन और मैन्युअल एनालिसिस पूरा हुआ, तब तक 61 LPE कमज़ोरियों के पैच अपस्ट्रीम प्रोजेक्ट में शामिल किए जा चुके थे, 43 के पैच स्टेजिंग में थे और 299 कमज़ोरियों की रिपोर्ट की जा रही थी और उन पर सार्वजनिक रूप से चर्चा हो रही थी.

हम Linux के उन मेंटेनर्स के काम की बहुत सराहना करते हैं, जो पहचानी गई कमज़ोरियों के लिए तेज़ी से पैच तैयार कर रहे हैं. साथ ही, हम अपने रिसर्च के नतीजे शेयर करने वाली बड़ी सिक्योरिटी कम्युनिटी की भी सराहना करते हैं. दुनिया भर के सॉफ़्टवेयर को सुरक्षित रखने के लिए इसी तरह मिलकर काम करने की ज़रूरत है. जिस तेज़ी से कमज़ोरियों की जानकारी सामने आ रही है और उनके पैच तैयार हो रहे हैं, उससे यह भी साफ़ होता है कि यूज़र्स और कंपनियों के लिए अपने सॉफ़्टवेयर को अपडेट रखना कितना ज़रूरी है.

मुख्य सीख: ऑटोमेटेड ट्रायेज में पैच तेज़ी से तैयार होने और लागू होने के प्रोसेस का ध्यान रखना चाहिए. सबसे नए कोड के आधार पर कमज़ोरियों का दोबारा वैलिडेशन करने से डुप्लिकेट या पुरानी हो चुकी रिपोर्ट्स से बचा जा सकता है. इसमें वह नया कोड भी शामिल होना चाहिए, जिसे शुरुआती स्कैन के बाद मर्ज किया गया था. इससे फ़ोकस उन कमज़ोरियों पर रहता है जो अब तक ठीक नहीं हुई हैं. साथ ही, मेंटेनर्स को ऐसे सबूत मिलते हैं जिनके आधार पर वे कार्रवाई कर सकते हैं, बिना उनके रिव्यू का काम बेवजह बढ़ाए.

जब हम पाइपलाइन डेवलप कर रहे थे, तब जुलाई 2026 के आखिर में GPT‑5.6 Sol ने 166 अलग-अलग LPE कमज़ोरियाँ खोजीं और उनका फ़ायदा उठाया. इस पूरे प्रोसेस में API क्रेडिट्स के तौर पर कुल $513,690 खर्च हुए.

अक्टूबर 2026 के बीच में किए गए दूसरे स्कैन में नए साइबर मॉडल ने 948 अलग-अलग LPE कमज़ोरियाँ खोजीं और उनका फ़ायदा उठाया. इस पूरे प्रोसेस में API क्रेडिट्स के तौर पर कुल $1,213,430 खर्च हुए. दोनों कैंपेन्स में हमने उस समय उपलब्ध Linux कर्नेल की सबसे नई मास्टर ब्रांच को स्कैन किया था.

मुख्य सीख: मॉडल्स की क्षमताएँ बेहतर होने पर पहले ऑडिट किए गए कोड को दोबारा स्कैन करना चाहिए. ज़्यादा सक्षम मॉडल ऐसी कमज़ोरियाँ भी खोज सकता है, जिन्हें पहले के मॉडल्स नहीं ढूँढ पाए थे, भले ही उसी रिसर्च हार्नेस का इस्तेमाल किया जाए.

हमने एजेंट्स के डेवलप किए गए एक्सप्लॉइट्स में से 166 सैंपल चुने और उनमें इस्तेमाल की गई एक्सप्लॉइटेशन तकनीकों का एनालिसिस किया. हमारी जानकारी के मुताबिक, एजेंट्स ने इन सैंपल एक्सप्लॉइट्स में 10 नई एक्सप्लॉइटेशन तकनीकों का इस्तेमाल किया. हमने ये तकनीकें थर्ड-पार्टी कर्नेल एक्सप्लॉइटेशन एक्सपर्ट्स के साथ भी शेयर कीं. उनके लिए भी ये तकनीकें नई थीं.

इन 10 तकनीकों में से दो नई पर्सिस्टेंट इलास्टिक ऑब्जेक्ट तकनीकें हैं, जिनका इस्तेमाल मॉडल ने टारगेट कर्नेल कैश में बड़ी संख्या में ऑब्जेक्ट्स रखने के लिए किया. दो नई पेज ग्रूमिंग तकनीकें हैं, जो एक्सप्लॉइट के भरोसेमंद तरीके से काम करने की संभावना बढ़ाती हैं. पाँच नई डेटा-ओनली तकनीकें हैं, जिनसे सीधे या आर्बिट्रेरी राइट के ज़रिए प्रिविलेज एस्केलेशन हासिल किया जा सकता है. बाकी एक तकनीक आर्बिट्रेरी टाइप कन्फ़्यूज़न से जुड़ी है. सुरक्षा कारणों से हम इस पोस्ट में इन नई एक्सप्लॉइटेशन तकनीकों की पूरी टेक्निकल जानकारी शेयर नहीं कर रहे हैं.

मुख्य सीख: फ़्रंटियर मॉडल्स सिर्फ़ पहले से पहचाने गए कमज़ोर कोड पैटर्न्स को मैच नहीं करते या सिर्फ़ मौजूदा एक्सप्लॉइटेशन तकनीकों का इस्तेमाल नहीं करते. वे क्रिएटिविटी दिखाते हैं और नए तरीके भी खोजते हैं.

हमारी टीम के मिशन का एक अहम हिस्सा यह पता लगाना है कि कमज़ोरियाँ ढूँढने और उनका फ़ायदा उठाने में कितना खर्च आता है. फिर इस जानकारी के आधार पर सिक्योरिटी को बेहतर बनाने के लिए निवेश की दिशा तय करना है. हमारा लक्ष्य डिफ़ेंडर्स की मदद करना है, ताकि वे अटैकर्स के फ़ायदा उठाने से पहले ही कमज़ोरियों को ठीक कर सकें. साथ ही, सॉफ़्टवेयर की कमज़ोरियों का फ़ायदा उठाना अटैकर्स के लिए इतना महँगा बनाना है कि ऐसा करना उनके लिए फ़ायदेमंद न रहे. एक्सप्लॉइट तैयार करने का खर्च मापने से हमें यह समझने में मदद मिलती है कि मॉडल्स की क्षमताएँ बढ़ने के साथ यह चैलेंज कैसे बदल रहा है. इस सेक्शन में हमने अपनी पाइपलाइन चलाने के खर्च की तुलना, ढूँढी गई कमज़ोरियों के लिए बग बाउंटी प्रोग्राम्स में मिलने वाले रिवॉर्ड्स से की है.

हमारे एक्सपेरिमेंट में टारगेट वर्चुअल मशीनों पर एक स्टैंडर्ड डेस्कटॉप ऑपरेटिंग सिस्टम चल रहा था. हमने जान-बूझकर कमज़ोर बनाया गया कोई टारगेट इस्तेमाल नहीं किया. इसमें वही थ्रेट मॉडल इस्तेमाल हुआ, जो साइबर सिक्योरिटी कॉम्पिटिशन्स (जैसे Pwn2Own⁠(एक नई विंडो में खुलेगा) और TyphoonPWN⁠(एक नई विंडो में खुलेगा)) में इस्तेमाल होता है. पहले Linux कर्नेल के लोकल प्रिविलेज एस्केलेशन एक्सप्लॉइट्स के लिए Pwn2Own में $20,000 और TyphoonPWN में $70,000 की बग बाउंटी मिलती थी. अगर इन पुरानी बाउंटी की रकम को 948 एक्सप्लॉइट्स पर लागू करें, तो उनकी अनुमानित वैल्यू $1.89 करोड़ से $6.63 करोड़ होती है. यह हमारी पाइपलाइन के खर्च से लगभग 16x से 55x ज़्यादा है.

हमने Google के kernelCTF⁠(एक नई विंडो में खुलेगा) वल्नरेबिलिटी रिवॉर्ड प्रोग्राम पर भी अपनी पाइपलाइन टेस्ट की. इसमें टारगेट के तौर पर एक ज़्यादा सुरक्षित Linux कर्नेल इस्तेमाल होता है, जिसमें अटैक के रास्ते कम होते हैं. हमने kernelCTF के एनवायरनमेंट में Linux कर्नेल के लेटेस्ट वर्ज़न पर पाइपलाइन चलाई. यह वर्ज़न kernelCTF के SLAB_VIRTUAL मिटिगेशन के साथ कम्पैटिबल नहीं था, इसलिए हमने इसे कॉन्फ़िगरेशन से हटा दिया. इस टेस्ट में हमें इन्फ़ॉर्मेशन लीक के 25 प्रूफ़ ऑफ़ कॉन्सेप्ट और 21 लोकल प्रिविलेज एस्केलेशन एक्सप्लॉइट्स मिले. तुलना के लिए, यह लेख लिखे जाने तक kernelCTF ने 2026 में 26 कन्फ़र्म किए गए 0-day LPE एक्सप्लॉइट्स स्वीकार किए थे. पूरा टेस्ट कुल 112 घंटे चला और इसमें लगभग $32,936 के API क्रेडिट्स खर्च हुए. API के कुल खर्च में वल्नरेबिलिटी डिस्कवरी की हिस्सेदारी 83.7% थी. अगर प्रोग्राम इन 21 कमज़ोरियों को स्वीकार कर लेता, तो लगभग $15 करोड़ की बाउंटी मिल सकती थी. यह खर्च से लगभग 45x ज़्यादा होता.

मुख्य बात: बाउंटी के लिए घोषित रकम के आधार पर, इस रिसर्च के समय मौजूदा साइबर क्षमताओं वाले मॉडल्स के साथ हमारी वल्नरेबिलिटी रिसर्च पाइपलाइन खर्च निकालने के बाद भी फ़ायदे में थी. डिफ़ेंडर्स को अपने सॉफ़्टवेयर का पहले से एनालिसिस करना चाहिए, ताकि अटैकर्स के लिए उसकी कमज़ोरियों का फ़ायदा उठाना इतना महँगा हो जाए कि ऐसा करना उनके लिए फ़ायदेमंद न रहे.

एक्सप्लॉइटेबिलिटी असेसमेंट के दौरान ExploitDev एजेंट्स को एक वल्नरेबिलिटी रिपोर्ट दी गई और पूरी तरह काम करने वाला एक्सप्लॉइट बनाने का टास्क दिया गया. अगर रूट शेल का एक्सेस मिल जाता था, तो हमारी पाइपलाइन उस कमज़ोरी को सफलतापूर्वक एक्सप्लॉइट किया गया मानती थी. शुरुआती रन में एक्सप्लॉइटेशन स्टेज ने 200 सफल लोकल प्रिविलेज एस्केलेशन एक्सप्लॉइट्स रिपोर्ट किए. लेकिन जब रिसर्चर्स ने इन्हें रिव्यू किया, तो पता चला कि इनमें से 20 मामलों में एजेंट्स ने दी गई कमज़ोरी के बजाय किसी दूसरी 0-day कमज़ोरी का इस्तेमाल करके रूट प्रिविलेज हासिल किए थे. इससे पता चलता है कि एजेंट्स के सफल एक्सप्लॉइट्स का भी सही तरीके से वैलिडेशन करना ज़रूरी है.

इसके बाद हमने टास्क से जुड़ी पाबंदियाँ और सख्त कीं और एक अलग चेक जोड़ा, ताकि यह पक्का किया जा सके कि हर फ़ाइनल एक्सप्लॉइट में उसी कमज़ोरी का इस्तेमाल हुआ है, जो उसे असाइन की गई थी.

मुख्य बात: ऑटोनॉमस सिक्योरिटी रिसर्च में सिर्फ़ नतीजे को वैलिडेट करना काफ़ी नहीं है. यह भी देखना ज़रूरी है कि उस नतीजे तक कैसे पहुँचा गया. इसके लिए अलग-थलग एनवायरनमेंट, मॉनिटरिंग और स्वतंत्र चेक ज़रूरी हैं.

इस रिसर्च की शुरुआत में हमने यह जाँचा कि एजेंट की साइबर क्षमताएँ बेहतर बनाने के लिए उसके आसपास एक जटिल ऑर्केस्ट्रेशन सिस्टम बनाना चाहिए या नहीं. हमारे नतीजों से पता चला कि ज़्यादा सक्षम मॉडल्स को कम ऑर्केस्ट्रेशन और कम स्टेप-बाय-स्टेप गाइडेंस की ज़रूरत होती है. साथ ही, इससे मिलने वाला मामूली सुधार मेंटेनेंस के खर्च के हिसाब से फ़ायदेमंद नहीं था. इसलिए हमने जटिल ऑर्केस्ट्रेशन हटाने का फ़ैसला किया.

इस एक्सपेरिमेंट में GPT‑5.5 Cyber और GPT‑5.6 Cyber की तुलना की गई. हमने देखा कि GPT‑5.5 Cyber लगातार सही तरीके से यह नहीं पहचान पा रहा था कि Linux कर्नेल की मौजूदा एक्सप्लॉइटेशन तकनीकों को कब और कैसे इस्तेमाल करना है. इसके बाद हमने 103 तकनीकों को ऐसे फ़ॉर्मैट में तैयार किया, जिसे मॉडल आसानी से समझ सके. हमने इन्हें एजेंट के एनवायरनमेंट में उपलब्ध कराया और एजेंट को इनका इस्तेमाल करने के लिए कहा. इससे 63 एक्सप्लॉइटेशन कैंडिडेट्स पर सक्सेस रेट 76.2% से बढ़कर 88.9% हो गया.

जब हमने GPT‑5.6 Cyber के साथ यही एक्सपेरिमेंट दोहराया, तो मॉडल अपने आप सही तकनीकें ढूँढने, चुनने और इस्तेमाल करने में बेहतर साबित हुआ. हमने तकनीकों और स्किल्स से जुड़ा ऑर्केस्ट्रेशन हटा दिया. इसके बाद कम ऑर्केस्ट्रेशन वाले GPT‑5.6 Cyber वर्कफ़्लो ने ज़्यादा सपोर्ट और गाइडेंस वाले GPT‑5.5 Cyber वर्कफ़्लो से बेहतर परफ़ॉर्म किया. GPT‑5.6 Cyber में तकनीकों की अतिरिक्त लेयर दोबारा जोड़ने से सिर्फ़ 1.5 प्रतिशत पॉइंट का मामूली सुधार हुआ.

मुख्य बात: बेस मॉडल की क्षमताएँ बदलने के साथ अपने ऑर्केस्ट्रेशन और हार्नेस का दोबारा इवैल्यूएट करें. जो अतिरिक्त सपोर्ट एक मॉडल जेनरेशन की परफ़ॉर्मेंस में काफ़ी सुधार लाता है, हो सकता है कि वह ज़्यादा सक्षम मॉडल के लिए उतना फ़ायदेमंद न हो. इसलिए उससे मिलने वाले फ़ायदे और मेंटेनेंस के खर्च की तुलना करना ज़रूरी है.

शुरुआत में, जब मॉडल को सीधे संभावित पैच जनरेट करने के लिए कहा जाता था, तो वह ऐसे पैच बनाता था जो काम सही तरीके से करते थे और प्रूफ़ ऑफ़ कॉन्सेप्ट में दिखाई गई कमज़ोरी को दूर करते थे. लेकिन कभी-कभी इनसे दूसरी समस्याएँ भी पैदा हो जाती थीं. जैसे, ज़रूरत से ज़्यादा कोड जोड़ना, परफ़ॉर्मेंस पर संभावित असर पड़ना, कोडिंग के तय तरीकों से अलग जाना या उसी कमज़ोरी के दूसरे वैरिएंट्स के लिए संबंधित कोड की जाँच न करना. इससे कुछ पैच अधूरे रह जाते थे.

अतिरिक्त निर्देश देने और पैच जेनरेशन प्रोसेस में बार-बार सुधार करने से पैच की क्वालिटी बेहतर हुई. इससे पता चलता है कि सही तरीके से काम करने पर AI से ऐसे सिक्योरिटी पैच जनरेट करवाए जा सकते हैं, जो सही हों, जिनमें सिर्फ़ ज़रूरी बदलाव हों और जो मौजूदा कोडिंग के तरीकों के मुताबिक हों. इस क्षेत्र में अभी रिसर्च चल रही है और हमारा मानना है कि आने वाले मॉडल्स के साथ यह काम और आसान और असरदार होगा. कुछ मामलों में हमारा रिसर्च प्रोटोटाइप, ह्यूमन एक्सपर्ट्स के लिखे पैच में भी समस्याएँ ढूँढ पाया. इन समस्याओं को पैच मर्ज होने से पहले ठीक कर दिया गया.

मुख्य बात: मॉडल्स पैचिंग प्रोसेस को तेज़ कर सकते हैं. लेकिन पैचिंग स्किल्स और हार्नेस में बार-बार सुधार करना पड़ सकता है, ताकि पैच भरोसेमंद तरीके से फ़ंक्शनल और नॉन-फ़ंक्शनल, दोनों तरह की ज़रूरतें पूरी करें. इसके अलावा, हम ह्यूमन एक्सपर्ट्स और AI के बनाए पैच की जाँच के लिए भी मॉडल्स इस्तेमाल करने की सलाह देते हैं. इस जाँच में पैच को बायपास करने या उसमें कमियाँ ढूँढने की कोशिश की जाती है. इससे ऐसी समस्याएँ पकड़ी जा सकती हैं, जैसे पैच को बायपास किया जा सकना या अटैक के दूसरे रास्तों और कमज़ोरी के वैरिएंट्स का छूट जाना.

हमारे kernelCTF रन में रिसर्च प्रोटोटाइप ने Linux कर्नेल के 21 0-day एक्सप्लॉइट्स के अलावा QEMU TCG की एक कमज़ोरी भी ढूँढी और उसका फ़ायदा उठाया. एनालिस्ट एजेंट को सिस्टम कॉल एंट्री कोड का एनालिसिस करने का टास्क दिया गया था. प्रिविलेज ट्रांज़िशन्स पर एक्सपेरिमेंट करने के लिए प्रोग्राम लिखते समय उसे कर्नेल में एक ऐसा क्रैश मिला, जिसकी उम्मीद नहीं थी. एजेंट ने क्रैश की जाँच की और QEMU के सोर्स कोड का एक्सेस न होने के बावजूद समस्या का पता QEMU TCG में लगाया. उसने इस कमज़ोरी को रिपोर्ट में भी शामिल किया. इसके बाद ExploitDev एजेंट ने इस कमज़ोरी के लिए सफलतापूर्वक एक लोकल प्रिविलेज एस्केलेशन एक्सप्लॉइट तैयार किया. एक्सप्लॉइट्स का मैन्युअल एनालिसिस करते समय हमें QEMU की इस कमज़ोरी का पता चला. हमने यह भी कन्फ़र्म किया कि अपस्ट्रीम QEMU में यह कमज़ोरी ठीक कर दी गई थी, लेकिन एक्सपेरिमेंट में इस्तेमाल किए गए रिलीज़ बिल्ड में यह अभी भी मौजूद थी.

मुख्य बात: एडवांस साइबर क्षमताओं वाले फ़्रंटियर मॉडल्स टेस्टिंग इंफ़्रास्ट्रक्चर में भी कमज़ोरियाँ ढूँढ सकते हैं. हम सलाह देते हैं कि ऑफ़ेंसिव वल्नरेबिलिटी रिसर्च करने से पहले इंफ़्रास्ट्रक्चर के हर हिस्से को टेस्ट किया जाए. हमने पहले से अपने इंफ़्रास्ट्रक्चर की टेस्टिंग की है और Kata, Moby/Docker, gVisor और दूसरे प्रोजेक्ट्स की कई कमज़ोरियों की जानकारी शेयर करके उन्हें पैच किया है.

हमारा लक्ष्य मॉडल्स की बढ़ती क्षमताओं को इंटरनेट को सुरक्षित रखने वाले लोगों के लिए लंबे समय तक फ़ायदेमंद बनाना है. यह रिसर्च दिखाती है कि फ़्रंटियर मॉडल्स की बढ़ती साइबर क्षमताओं का इस्तेमाल Linux कर्नेल जैसे जटिल सॉफ़्टवेयर में कमज़ोरियाँ असरदार तरीके से ढूँढने के लिए किया जा सकता है. Linux और दूसरे ओपन-सोर्स प्रोजेक्ट्स जैसे अहम सॉफ़्टवेयर की सिक्योरिटी मज़बूत करने से उन पर निर्भर कई सिस्टम्स और यूज़र्स को सुरक्षित रखा जा सकता है.

Daybreak की पहल Patch the Planet के ज़रिए, हम इस रिसर्च को और ज़्यादा अहम सॉफ़्टवेयर प्रोजेक्ट्स तक ले जाना चाहते हैं. साथ ही, मेंटेनर्स और सिक्योरिटी पार्टनर्स के साथ मिलकर एक भरोसेमंद ऑटोमेटेड पैचिंग सिस्टम डेवलप करना चाहते हैं. हमारा मकसद अटैकर्स के लिए उपलब्ध मौकों को धीरे-धीरे कम करना और कमज़ोरियाँ ढूँढकर उनका फ़ायदा उठाने की लागत बढ़ाना है, ताकि एक समय ऐसा आए जब अटैक से मिलने वाला संभावित फ़ायदा उसकी लागत और मेहनत के मुकाबले बहुत कम रह जाए.

मॉडल्स की हर नई जेनरेशन की मदद से हमें ऐसा सॉफ़्टवेयर बनाना चाहिए, जिसकी सिक्योरिटी को तोड़ना अगली जेनरेशन के लिए और मुश्किल हो. हम इंटरनेट को सुरक्षित बनाने की दिशा में काम करते रहेंगे, ताकि कोई भी उस पर बेफ़िक्र होकर और खुशी-खुशी नई चीज़ें बना सके.