एआई उपकरणों द्वारा तैयार की गई भेद्यता रिपोर्ट के कारण समस्याएँ

नेटवर्क कर्ल पर डेटा प्राप्त करने और भेजने के लिए उपयोगिता के लेखक डैनियल स्टेनबर्ग ने भेद्यता रिपोर्ट बनाते समय एआई टूल के उपयोग की आलोचना की। ऐसी रिपोर्टों में विस्तृत जानकारी शामिल होती है, वे सामान्य भाषा में लिखी जाती हैं और उच्च गुणवत्ता वाली दिखती हैं, लेकिन वास्तविकता में विचारशील विश्लेषण के बिना वे केवल भ्रामक हो सकती हैं, वास्तविक समस्याओं को गुणवत्तापूर्ण दिखने वाली कचरा सामग्री से बदल देती हैं।

कर्ल परियोजना नई कमजोरियों की पहचान करने के लिए पुरस्कार का भुगतान करती है और पहले से ही संभावित समस्याओं की 415 रिपोर्ट प्राप्त कर चुकी है, जिनमें से केवल 64 को कमजोरियों के रूप में और 77 को गैर-सुरक्षा बग के रूप में पुष्टि की गई थी। इस प्रकार, सभी रिपोर्टों में से 66% में कोई उपयोगी जानकारी नहीं थी और केवल डेवलपर्स से समय लिया गया जिसे किसी उपयोगी चीज़ पर खर्च किया जा सकता था।

डेवलपर्स को बेकार रिपोर्टों को पार्स करने और वहां मौजूद जानकारी को कई बार दोबारा जांचने में बहुत समय बर्बाद करने के लिए मजबूर होना पड़ता है, क्योंकि डिज़ाइन की बाहरी गुणवत्ता जानकारी में अतिरिक्त विश्वास पैदा करती है और ऐसा लगता है कि डेवलपर ने कुछ गलत समझा है। दूसरी ओर, इस तरह की रिपोर्ट तैयार करने के लिए आवेदक को न्यूनतम प्रयास की आवश्यकता होती है, जो वास्तविक समस्या की जांच करने की जहमत नहीं उठाता है, बल्कि पुरस्कार प्राप्त करने के संघर्ष में भाग्य की उम्मीद करते हुए, एआई सहायकों से प्राप्त डेटा को आँख बंद करके कॉपी कर लेता है।

ऐसी कचरा रिपोर्ट के दो उदाहरण दिए गए हैं। खतरनाक अक्टूबर भेद्यता (सीवीई-2023-38545) के बारे में जानकारी के नियोजित प्रकटीकरण से एक दिन पहले, हैकरोन के माध्यम से एक रिपोर्ट भेजी गई थी कि फिक्स वाला पैच सार्वजनिक रूप से उपलब्ध हो गया था। वास्तव में, रिपोर्ट में समान समस्याओं के बारे में तथ्यों का मिश्रण और Google के AI सहायक बार्ड द्वारा संकलित पिछली कमजोरियों के बारे में विस्तृत जानकारी के अंश शामिल थे। परिणामस्वरूप, जानकारी नई और प्रासंगिक लग रही थी, और उसका वास्तविकता से कोई संबंध नहीं था।

दूसरा उदाहरण 28 दिसंबर को वेबसॉकेट हैंडलर में बफर ओवरफ़्लो के बारे में प्राप्त एक संदेश से संबंधित है, जो एक उपयोगकर्ता द्वारा भेजा गया था जिसने पहले ही हैकरोन के माध्यम से विभिन्न परियोजनाओं को कमजोरियों के बारे में सूचित कर दिया था। समस्या को पुन: प्रस्तुत करने की एक विधि के रूप में, रिपोर्ट में स्ट्रैपी के साथ प्रतिलिपि बनाते समय उपयोग किए गए बफर के आकार से बड़े मूल्य के साथ एक संशोधित अनुरोध पारित करने के बारे में सामान्य शब्द शामिल थे। रिपोर्ट में सुधार का एक उदाहरण भी दिया गया (strcpy को strncpy से बदलने का एक उदाहरण) और कोड की लाइन "strcpy(keyval, randstr)" के लिए एक लिंक का संकेत दिया गया, जिसमें आवेदक के अनुसार, एक त्रुटि थी।

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

स्रोत: opennet.ru