रूटपर्यंत पोहोचण्याचे एक हजार कमी मार्ग

पूर्वी सुरक्षा संशोधनात प्रत्येक निष्कर्षासाठी स्वतंत्र, दीर्घ तपास करावा लागत असे. आता ते अधिकाधिक पद्धतशीर प्रक्रियेच्या स्वरूपात करता येत आहे. या दस्तऐवजात या क्षेत्रातील आमच्या एका प्रयत्नाचा आढावा घेतला आहे.

मोठ्या प्रमाणावर असुरक्षा शोधणे सोपे होत आहे, मात्र प्राधान्यक्रम ठरवणे आणि पडताळणी करणे हे अजूनही कामाच्या गतीतील अडथळे आहेत. नियंत्रित संशोधन वातावरणात Linux कर्नलमधील सुरक्षा त्रुटी शोधण्यासाठी आम्ही एक प्रायोगिक प्रणाली तयार केली. या प्रणालीने Linux कर्नलमधील 2,308 संभाव्य असुरक्षा ओळखून त्यांचे विश्लेषण केले, 1,724 असुरक्षा प्रत्यक्ष पुनरुत्पादित केल्या आणि विशेष अधिकार नसलेल्या स्थानिक वापरकर्त्याला रूट प्रवेश मिळवून देऊ शकणारे 948 स्थानिक अधिकारवाढीचे (LPE) हल्ला-प्रोग्राम तयार केले.

या पुराव्याच्या आधारे आम्ही असुरक्षांची नोंद करण्याचा प्राधान्यक्रम ठरवला आणि देखभालकर्त्यांच्या पुनरावलोकनासाठी प्रस्तावित दुरुस्त्या तयार केल्या. Linux कर्नल समुदायाच्या मार्गदर्शनानुसार आम्ही गंभीर असुरक्षांपासून सुरुवात केली आणि पुढील अहवाल व दुरुस्त्यांसाठी पॅच द प्लॅनेटच्या भागीदारांसोबत काम करत आहोत.

जूनमध्ये, आमच्या पॅच द प्लॅनेट उपक्रमांतर्गत, आम्ही सांगितले होते की GPT‑5.5 Cyber ने Linux कर्नलमधील असुरक्षा ओळखल्या आणि त्यांची पडताळणी व नोंद करण्यासाठी 24 स्थानिक अधिकारवाढीचे हल्ला-प्रोग्राम विकसित केले. आम्ही या कामाचा विस्तार करून आगामी सायबर मॉडेलवर चालणारी प्रक्रियास तयार केली. त्यात असुरक्षा शोध, प्रत्यक्ष चाचणीतील पडताळणी, गैरफायदा घेण्याच्या शक्यतेचे मूल्यांकन आणि दुरुस्ती-निर्मिती यांचा समावेश आहे. प्रक्रिया पूर्ण झाल्यावर मानवी संशोधकांनी निष्पन्नांचे पुनरावलोकन केले आणि सापडलेल्या असुरक्षा दुरुस्त्यांसह नोंदवल्या.

Linux कर्नल हा अब्जावधी लोक वापरत असलेली Android उपकरणे, क्लाउड पायाभूत यंत्रणा, महासंगणक आणि इतर प्रणालींचा पाया आहे. चार कोटींहून अधिक ओळींचा कोड असलेल्या कर्नलमध्ये प्रणाली-कॉल, नेटवर्किंग, फाइल प्रणाली आणि उपकरण चालकांद्वारे हल्ल्यासाठी व्यापक प्रवेशमार्ग उपलब्ध होतात. इतक्या मोठ्या आणि महत्त्वाच्या कोडसंचात अत्याधुनिक मॉडेल किती प्रभावीपणे असुरक्षा शोधू शकतात आणि त्यांचा सुरक्षेवरील परिणाम दाखवू शकतात, याचा अभ्यास करण्यासाठी आम्ही Linux निवडले.

असुरक्षा शोधाच्या सुरुवातीच्या टप्प्यात हजारो संभाव्य निष्कर्ष मिळाले. सुरक्षा संशोधकांनी स्वतः प्रत्येकाचे पुनरावलोकन आणि छाननी करणे शक्य होईल, त्यापेक्षा ही संख्या फार मोठी होती. आमच्या असुरक्षा शोध प्रक्रियासाखळीतील व्यावहारिक आव्हान शोध घेणे नव्हते. कोणते निष्कर्ष पुन्हा प्रत्यक्ष दाखवता येतील, ते कोणती सुरक्षा सीमा ओलांडतात आणि देखभालकर्त्यांनी सर्वप्रथम कोणत्याकडे लक्ष द्यावे, हे ठरवणे हे आव्हान होते.

जग ज्या सॉफ्टवेअरवर अवलंबून आहे ते सुरक्षित करण्यात मदत करणे, हे OpenAI च्या सायबर पथकाचे ध्येय आहे. हे काम पुन्हा करण्यासाठी आणि पुढे नेण्यासाठी लागणाऱ्या साधनसंपत्तीचा संशोधकांना अंदाज घेता यावा, म्हणून आम्ही प्रत्येक टप्प्याचा API खर्च नोंदवतो. हे खर्च या मूल्यांकनात वापरलेली मॉडेल, लक्ष्य संरचना आणि कार्यपद्धती यांवर आधारित आहेत. संरक्षणकर्त्यांना असुरक्षा शोधून दुरुस्त करण्यात मदत करणे, हल्लेखोरांच्या संधी कमी करणे आणि त्यांना सॉफ्टवेअरचा गैरफायदा घेण्यासाठी लागणारा खर्च वाढवणे, हे आमचे व्यापक ध्येय आहे.

शेवटी, लक्षात घ्या की या संशोधनात आम्ही खर्चाऐवजी कार्यपद्धती आणि मॉडेलची क्षमता मोजण्यावर भर दिला. हार्नेसच्या अभियांत्रिकीत पुरेशी सुधारणा केल्यास प्रत्येक टप्प्याचा खर्च लक्षणीयरीत्या कमी होऊ शकतो, अशी आमची अपेक्षा आहे. त्यामुळे आम्ही दिलेले खर्च हे साधारणपणे वरची मर्यादा दर्शवतात.

आमची प्रायोगिक असुरक्षा संशोधन प्रणाली ही पाच टप्प्यांची प्रक्रियासाखळी आहे. तिच्या केंद्रस्थानी आगामी सायबर मॉडेल आहे:

• असुरक्षा शोध: एजंट कोडसंचातील सुरक्षेशी संबंधित भाग ओळखतात आणि संभाव्य असुरक्षा शोधण्यासाठी ते तपासतात.

• प्रत्यक्ष चाचणीतील पडताळणी: एजंट प्रत्येक संभाव्य असुरक्षा विलग वातावरणात पुनरुत्पादित करण्याचा प्रयत्न करतात आणि अंमलबजावणीदरम्यानचा पुरावा जतन करतात. या पायरीतून पुनरुत्पादित आणि पडताळलेल्या असुरक्षा मिळतात.

• गैरफायदा घेण्याच्या शक्यतेचे मूल्यांकन: पडताळलेल्या असुरक्षांमुळे माहिती उघड होऊ शकते किंवा स्थानिक अधिकारवाढ होऊ शकते का, हे एजंट तपासतात.

• दुरुस्ती-निर्मिती: एजंट ओळखलेल्या प्रत्येक असुरक्षेवर दुरुस्ती तयार करतात.

• मानवी पुनरावलोकन: देखभालकर्त्यांना अहवाल देण्यापूर्वी सुरक्षा संशोधक हल्ला-प्रोग्राम, दुरुस्ती आणि प्रस्तावित तीव्रता यांचे पुनरावलोकन करतात.

प्रक्रियेच्या शेवटी प्रणाली मूळ कारणाचे विश्लेषण, प्रणाली बंद पाडणारे किमान संकल्पना-सिद्धता प्रात्यक्षिक, प्रस्तावित दुरुस्ती आणि पूर्ण हल्ला-प्रोग्राम एकत्र देते. त्यामुळे मानवी संशोधकांना असुरक्षेची तीव्रता ठरवणे आणि दुरुस्त्या मूळ प्रकल्पात समाविष्ट करणे सोपे जाते.

Linux कर्नलमधील कोडची प्रत्येक ओळ सुरक्षेशी संबंधित नसते. आमच्या प्रक्रियेने शोधक एजंटचा ग्रुप वापरून तपासणीसाठी महत्त्वाचे भाग ओळखले. त्यानंतर असुरक्षा शोधण्यासाठी हे भाग विश्लेषक एजंटकडे दिले.

शोधक एजंट प्रत्येक फोल्डर आणि फाइल वाचतात. कमी अधिकारांचे वापरकर्ते कोणत्या भागांपर्यंत पोहोचू शकतात आणि त्यांचा सुरक्षेशी किती संबंध आहे, यावरून कोणते भाग तपासायचे हे ठरवतात.

या टप्प्यात तपासणीसाठी 5,034 भाग निवडले गेले. त्यांत कोडच्या सुमारे 28 लाख ओळी होत्या—संपूर्ण Linux कर्नल कोडच्या जवळपास 7%. त्यामुळे संपूर्ण कोडचे विश्लेषण करण्याच्या तुलनेत सुरक्षा तपासणीचा खर्च लक्षणीयरीत्या कमी झाला. या पायरीसाठी API क्रेडिट्समध्ये $3,426 खर्च आला.

पुढे, विश्लेषक एजंटनी तपासणीसाठी निवडलेल्या प्रत्येक भागाचे विश्लेषण केले आणि Codex सुरक्षा प्लगइन⁠(नवीन विंडोमध्ये उघडेल)सारखी कार्यपद्धती वापरून संभाव्य असुरक्षांचे निष्कर्ष तयार केले. थोडक्यात, विश्लेषक एजंट नेमून दिलेल्या भागाचा कोड वाचून तो कसा काम करतो हे समजून घेतात, त्याला संभवणारे धोके ठरवतात आणि त्यातील असुरक्षा शोधतात.

12 तासांमध्ये, विश्लेषक एजंटनी पुनरावृत्ती वगळल्यानंतर 2,308 संभाव्य निष्कर्ष तयार केले. या टप्प्यासाठी API क्रेडिट्समध्ये $316,549 खर्च आला.

संभाव्य असुरक्षेचा निष्कर्ष म्हणजे पडताळलेली असुरक्षा नव्हे. इतक्या मोठ्या प्रमाणावर प्रत्येक अहवाल स्वतः तपासणे आमच्या संशोधन संघासाठी व्यवहार्य नाही.

म्हणून आम्ही अशा निष्कर्षांच्या पडताळणीवर भर दिला, जे a) कमी अधिकारांच्या वापरकर्त्यालाही उद्भववता येतात, b) ज्यांसाठी विशेष परवानग्यांची गरज नसते आणि c) ज्यांतून मेमरी बिघाडाचा मोजता येणारा पुरावा मिळतो.

प्रत्येक संभाव्य असुरक्षेसाठी, छाननी एजंटने संकल्पना-सिद्धता प्रात्यक्षिक तयार केले आणि Kernel Address Sanitizer (KASAN) असलेला Linux कर्नल चालवणाऱ्या विलग आभासी यंत्रात ते चालवले. एजंटने प्रोग्रामचे निष्पन्न आणि प्रणाली कन्सोल दोन्ही पाहिले. नोंदवलेले वर्तन पुन्हा घडेपर्यंत किंवा ते उद्भववण्याचे संभाव्य मार्ग संपेपर्यंत त्याने प्रात्यक्षिकात टप्प्याटप्प्याने सुधारणा केल्या.

30 तासांमध्ये, आमच्या प्रणालीने 1724 असुरक्षा पुनरुत्पादित केल्या—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 इतके क्रेडिट्स लागले. त्यामुळे सापडलेल्या असुरक्षांचा गैरफायदा घेता येतो का, हे तपासणे संरक्षणकर्त्यांसाठी तुलनेने स्वस्त ठरते.

प्राथमिक असुरक्षा छाननी एजंटसाठी API क्रेडिट्समध्ये $44,194 खर्च आला. हल्ला-विकास टप्प्यासाठी API क्रेडिट्समध्ये एकूण $775,929 खर्च आला. त्यापैकी $84,929 माहिती गळतीच्या संभाव्य प्रकरणांवर आणि $691,000 स्थानिक अधिकारवाढीच्या संभाव्य प्रकरणांवर खर्च झाले.

स्थानिक अधिकारवाढीच्या एका संभाव्य प्रकरणावर काम करण्याचा सरासरी खर्च ($558), माहिती गळतीच्या प्रकरणावरील खर्चाच्या ($271) सुमारे दुप्पट होता. याचे कारण म्हणजे माहिती गळतीची संकल्पना-सिद्धता प्रात्यक्षिके पडताळणी टप्प्यातूनच पुढे आणली होती आणि हल्ला-प्रोग्राममध्ये वापरण्यायोग्य होण्यासाठी त्यांमध्ये कमी बदल करावे लागले. याउलट, संभाव्य LPE प्रकरणातून हल्ला-प्रोग्राम तयार करताना हल्ल्याच्या धोरणाचे नियोजन, वापरता येतील असे असुरक्षित ऑब्जेक्ट ओळखणे, संरक्षणे चुकवणे अशा अनेक अतिरिक्त पायऱ्या आवश्यक होत्या. अयशस्वी हल्ला-प्रयत्नांचा खर्च (69 प्रकरणांसाठी $3,922) यशस्वी प्रयत्नांच्या खर्चापेक्षा (1169 प्रकरणांसाठी $360) खूप जास्त असल्याचेही दिसले. काही असुरक्षांचा गैरफायदा घेणे कठीण होते (उदा., रेस स्थिती), हे याचे कारण होते. एक तास कोणतीही प्रगती न झाल्यास प्रयत्न थांबवणे, अशी वाजवी थांबण्याची अट ठरवली असती, तर ExploitDev चा खर्च लक्षणीयरीत्या कमी झाला असता.

प्रत्येक प्रमाणित असुरक्षिततेसाठी, प्रणाली एक पॅच देखील तयार करते. आम्ही मॉडेलला संबंधित स्रोत कोड पुरवतो आणि पॅच लिहिण्याबाबतच्या सर्वोत्तम पद्धतींविषयी सूचना देतो; यामध्ये पॅचवर 'स्टॅटिक चेक' करणे, आसपासच्या कोडमध्ये वापरल्या जाणाऱ्या सॉफ्टवेअर विकास पद्धतींचे पालन करणे आणि पॅच पूर्ण असल्याची खात्री करण्यासाठी 'व्हेरिएंट ॲनालिसिस' करणे यांसारख्या गोष्टींचा समावेश असतो.

Linux कर्नल समुदायाच्या सूचनेनुसार, गंभीर असुरक्षांसाठी आम्ही शेकडो अहवाल आणि दुरुस्त्या आधीच पाठवल्या आहेत. उर्वरित दुरुस्त्या टप्प्याटप्प्याने पाठवण्यासाठी पॅच द प्लॅनेटच्या भागीदारांसोबत काम करत आहोत. मुक्त-स्रोत प्रकल्पांना पाठबळ देण्याच्या आमच्या व्यापक डेब्रेक वचनबद्धतेचा हे काम एक भाग आहे.

या विभागात आम्ही या संशोधनातून मिळालेली शिकवण, विचारमंथन आणि अतिरिक्त विश्लेषण मांडतो.

या संशोधनादरम्यान 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 शोषणांचे (exploits) नमुने घेतले आणि त्यामध्ये वापरल्या गेलेल्या शोषण तंत्रांचे विश्लेषण केले. आमच्या माहितीनुसार, या नमुन्यांमध्ये एजंटनी असुरक्षांचा गैरफायदा घेण्याची 10 नवीन तंत्रे वापरली. आम्ही ही तंत्रे बाह्य कर्नल हल्ला-तज्ञांना दाखवली आणि त्यांच्यासाठीही ती नवीन होती.

या 10 तंत्रांपैकी दोन नव्या टिकाऊ, लवचिक ऑब्जेक्टवर आधारित आहेत; मॉडेलने लक्ष्य कर्नल कॅशमध्ये मोठ्या प्रमाणावर ऑब्जेक्ट भरण्यासाठी त्यांचा वापर केला. दोन तंत्रे हल्ल्याची विश्वासार्हता वाढवण्यासाठी मेमरी पानांची मांडणी करतात. पाच तंत्रे केवळ डेटा बदलून, थेट किंवा इच्छित ठिकाणी लेखन करून अधिकारवाढ साधतात. उरलेल्या तंत्रात मनमानी प्रकार-गोंधळाचा वापर होतो. सुरक्षेच्या कारणास्तव, या नव्या हल्ला-तंत्रांचे संपूर्ण तांत्रिक तपशील आम्ही या लेखात देत नाही.

मुख्य शिकवण: अत्याधुनिक मॉडेल केवळ ज्ञात असुरक्षित कोडशी नमुने जुळवत नाहीत किंवा फक्त ज्ञात हल्ला-तंत्रे वापरत नाहीत; ती सर्जनशीलता आणि नवे दृष्टिकोनही दाखवतात.

असुरक्षा शोधण्याचा आणि त्यांचा गैरफायदा घेण्याचा खर्च मोजणे व त्या पुराव्याच्या आधारे संरक्षणातील गुंतवणुकीला दिशा देणे, हा आमच्या पथकाच्या ध्येयाचा महत्त्वाचा भाग आहे. हल्लेखोर वापर करू शकण्यापूर्वी संरक्षणकर्त्यांना असुरक्षा दुरुस्त करण्यात मदत करणे आणि सॉफ्टवेअरचा गैरफायदा घेणे हल्लेखोरांना आर्थिकदृष्ट्या परवडू न देणे, हे आमचे ध्येय आहे. गैरफायदा घेण्याचा खर्च मोजल्याने मॉडेलची क्षमता वाढताना हे आव्हान कसे बदलते, हे आम्हाला समजते. या विभागात आम्ही प्रक्रियासाखळी चालवण्याच्या खर्चाची, सापडलेल्या असुरक्षांसाठी दोषशोधन बक्षीस कार्यक्रमांत मिळणाऱ्या बक्षिसांशी तुलना करतो.

आमच्या प्रयोगातील लक्ष्य आभासी यंत्रांवर नेहमीची डेस्कटॉप कार्यप्रणाली चालत होती; तिची सुरक्षा मुद्दाम कमी केलेली नव्हती. सायबरसुरक्षा स्पर्धांमध्ये (उदा. Pwn2Own⁠(नवीन विंडोमध्ये उघडेल), TyphoonPWN⁠(नवीन विंडोमध्ये उघडेल)) वापरली जाणारीच धोक्याची गृहीतके येथे वापरली होती. पूर्वी Pwn2Own आणि TyphoonPWN यांनी Linux कर्नलमधील स्थानिक अधिकारवाढीच्या हल्ला-प्रोग्रामसाठी अनुक्रमे $20,000 आणि $70,000 इतकी दोषशोधन बक्षिसे देऊ केली होती. पूर्वीची ही बक्षिसे 948 हल्ला-प्रोग्रामना लागू केल्यास काल्पनिक मूल्य $18.9 दशलक्ष—$66.3 दशलक्ष होते, म्हणजे आमच्या प्रक्रियासाखळीच्या खर्चाच्या सुमारे 16 ते 55 पट.

आम्ही Google च्या kernelCTF⁠(नवीन विंडोमध्ये उघडेल) असुरक्षा बक्षीस कार्यक्रमावरही प्रक्रियासाखळीची चाचणी केली. त्यात हल्ल्यासाठी उपलब्ध प्रवेशबिंदू कमी केलेला आणि सुरक्षा बळकट केलेला Linux कर्नल लक्ष्य म्हणून वापरला जातो. kernelCTF वातावरणात Linux कर्नलच्या नवीनतम आवृत्तीवर प्रक्रियासाखळी चालवून आम्हाला माहिती गळतीची 25 संकल्पना-सिद्धता प्रात्यक्षिके आणि स्थानिक अधिकारवाढीचे 21 हल्ला-प्रोग्राम मिळाले. ही आवृत्ती kernelCTF मधील SLAB_VIRTUAL संरक्षणाशी विसंगत असल्याने आम्ही ते संरचनेतून वगळले. तुलनेसाठी, हा मजकूर लिहिताना kernelCTF ने 2026 मध्ये 26 पुष्टी केलेले शून्य-दिवस LPE हल्ला-प्रोग्राम स्वीकारले होते. संपूर्ण मोहीम 112 तास चालली. API क्रेडिट्समध्ये सुमारे $32,936 खर्च आला, त्यापैकी 83.7% API खर्च असुरक्षा शोधावर झाला. या कार्यक्रमाने त्या 21 असुरक्षा स्वीकारल्या असत्या, तर सुमारे $1.5 दशलक्ष बक्षीस मिळाले असते, म्हणजे खर्चाच्या सुमारे 45 पट.

मुख्य शिकवण: सार्वजनिक बक्षीस रकमांच्या आधारे पाहिल्यास, या संशोधनाच्या वेळी उपलब्ध सायबर-सक्षम मॉडेल वापरणारी आमची असुरक्षा संशोधन प्रक्रिया खर्च वजा करूनही नफा देणारी ठरली होती. हल्लेखोरांना गैरफायदा घेणे आर्थिकदृष्ट्या परवडू नये, यासाठी संरक्षणकर्त्यांनी आधीच पुढाकार घेऊन आपल्या सॉफ्टवेअरचे विश्लेषण करावे.

गैरफायदा घेण्याच्या शक्यतेचे मूल्यांकन करताना ExploitDev एजंटना असुरक्षेचा अहवाल देऊन पूर्णपणे कार्यरत हल्ला-प्रोग्राम तयार करण्याचे काम दिले होते. रूट शेल यशस्वीपणे मिळाल्यास आमची प्रक्रियासाखळी त्या असुरक्षेचा गैरफायदा घेण्यात यश आल्याची नोंद करत होती. सुरुवातीच्या एका फेरीत, हल्ला-विकास टप्प्याने स्थानिक अधिकारवाढीचे 200 यशस्वी हल्ला-प्रोग्राम नोंदवले. मात्र मानवी पुनरावलोकनानंतर असे आढळले की यांपैकी 20 प्रोग्रामनी नेमून दिलेल्या असुरक्षेऐवजी वेगळ्या शून्य-दिवस असुरक्षेद्वारे रूट अधिकार मिळवले होते. यावरून एजंटनी यशस्वीपणे गैरफायदा घेतला तरी त्याची योग्य पडताळणी आवश्यक असल्याचे दिसते.

त्यानंतर आम्ही कामाच्या मर्यादा अधिक काटेकोर केल्या आणि प्रत्येक अंतिम हल्ला-प्रोग्राम नेमून दिलेलीच असुरक्षा वापरतो याची खात्री करणारी स्वतंत्र तपासणी जोडली.

मुख्य शिकवण: स्वायत्त सुरक्षा संशोधनात केवळ निकाल नव्हे, तर तो मिळवण्यासाठी वापरलेला मार्गही पडताळा. विलगीकरण, देखरेख आणि स्वतंत्र तपासण्या ही आवश्यक नियंत्रणे आहेत.

या संशोधनाच्या सुरुवातीला, एजंटची सायबर क्षमता वाढवण्यासाठी त्याभोवती विस्तृत समन्वय-नियंत्रण यंत्रणा उभारावी का, या रचनात्मक पर्यायाचा आम्ही अभ्यास केला. आमच्या निष्कर्षांनुसार, अधिक सक्षम मॉडेलना कमी समन्वय-नियंत्रण आणि टप्प्याटप्प्याच्या मार्गदर्शनाची गरज असते. तसेच त्यातून होणारी किरकोळ सुधारणा देखभालीच्या खर्चाच्या मानाने पुरेशी ठरत नाही. त्यामुळे आम्ही विस्तृत समन्वय-नियंत्रण यंत्रणा काढून टाकण्याचे ठरवले.

या प्रयोगात GPT‑5.5 Cyber आणि GPT‑5.6 Cyber यांची तुलना केली. आमच्या निरीक्षणात, Linux कर्नलवरील हल्ल्यांची विद्यमान तंत्रे कधी आणि कशी वापरायची हे GPT‑5.5 Cyber ला सातत्याने ओळखता येत नव्हते. मग आम्ही 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 शून्य-दिवस हल्ला-प्रोग्रामव्यतिरिक्त, प्रायोगिक संशोधन प्रणालीने QEMU TCG मधील एक असुरक्षाही शोधली आणि तिचा गैरफायदा घेतला. विश्लेषक एजंटला प्रणाली-कॉल प्रवेश कोडचे विश्लेषण करण्याचे काम दिले होते. अधिकार-स्तरांतील बदलांवर प्रयोग करण्यासाठी प्रोग्राम लिहिताना त्याला कर्नल अनपेक्षितपणे बंद पडल्याचे आढळले. QEMU च्या स्रोत कोडचा प्रवेश नसतानाही, त्याने या बिघाडाची छाननी करून समस्येचा माग QEMU TCG पर्यंत शोधला आणि अहवालात ही असुरक्षा समाविष्ट केली. त्यानंतर ExploitDev एजंटने या असुरक्षेसाठी स्थानिक अधिकारवाढीचा हल्ला-प्रोग्राम यशस्वीपणे विकसित केला. हल्ला-प्रोग्रामचे मानवी विश्लेषण करताना आम्हाला ही QEMU असुरक्षा सापडली. मूळ QEMU प्रकल्पात ती दुरुस्त झाली होती, पण प्रयोगात वापरलेल्या प्रकाशित आवृत्तीत ती दुरुस्ती नव्हती, याची आम्ही खात्री केली.

मुख्य शिकवण: अत्याधुनिक सायबर-सक्षम मॉडेल चाचणीच्या पायाभूत यंत्रणेतील असुरक्षा शोधू शकतात. आक्रमक पद्धतीने असुरक्षा संशोधन करण्यापूर्वी पायाभूत यंत्रणेतील प्रत्येक भागाची चाचणी करण्याची आम्ही शिफारस करतो. आम्ही पुढाकार घेऊन आमच्या पायाभूत यंत्रणेची चाचणी केली आहे आणि Kata, Moby/Docker, gVisor तसेच इतर प्रकल्पांतील अनेक असुरक्षा उघड करून दुरुस्त केल्या आहेत.

मॉडेलची वाढती क्षमता इंटरनेट सुरक्षित ठेवणाऱ्यांसाठी दीर्घकाळ उपयोगी ठरावी, हे आमचे ध्येय आहे. अत्याधुनिक मॉडेलची वाढती सायबर क्षमता Linux कर्नलसारख्या गुंतागुंतीच्या सॉफ्टवेअरमधील असुरक्षा प्रभावीपणे शोधण्यासाठी वापरता येते, हे या संशोधनातून दिसते. Linux आणि इतर मुक्त-स्रोत प्रकल्पांसारख्या महत्त्वाच्या सॉफ्टवेअर प्रकल्पांची सुरक्षा बळकट केल्याने त्यांवर अवलंबून असलेल्या अनेक प्रणाली आणि वापरकर्त्यांचे संरक्षण होऊ शकते.

डेब्रेक उपक्रमाचा भाग असलेल्या पॅच द प्लॅनेटद्वारे, हे संशोधन आणखी महत्त्वाच्या सॉफ्टवेअर प्रकल्पांपर्यंत नेण्याचे आणि देखभालकर्ते व सुरक्षा भागीदारांसोबत विश्वासार्ह स्वयंचलित दुरुस्ती विकसित करणे हे आमचे उद्दिष्ट आहे. आम्हाला हल्लेखोरांना उपलब्ध असलेल्या संधी सातत्याने कमी करायच्या आहेत आणि असुरक्षितता शोधण्याचा व त्यांचा गैरफायदा घेण्याचा खर्च वाढवायचा आहे, जेणेकरून हल्ल्यातून अपेक्षित लाभ त्यासाठी लागणाऱ्या खर्चाच्या मानाने पुरेसा राहणार नाही.

मॉडेलच्या प्रत्येक जनरेशनने आपल्याला असे सॉफ्टवेअर तयार करण्यात मदत केली पाहिजे, ज्याची सुरक्षा भेदणे पुढच्या जनरेशनला अधिक कठीण जाईल. ज्यावर कोणीही आनंदाने नवनिर्मिती करू शकेल, असे सुरक्षित इंटरनेट उभारण्यासाठी आम्ही प्रयत्न करत राहू.