AI उपकरणहरू द्वारा तयार गरिएको भेद्यता रिपोर्टहरूको कारण समस्याहरू

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

Curl परियोजनाले नयाँ कमजोरीहरू पहिचान गर्नका लागि पुरस्कारहरू भुक्तान गर्दछ र पहिले नै सम्भावित समस्याहरूको 415 रिपोर्टहरू प्राप्त गरिसकेको छ, जसमध्ये केवल 64 लाई कमजोरीहरू र 77 गैर-सुरक्षा बगहरूको रूपमा पुष्टि गरिएको थियो। यसरी, सबै रिपोर्टहरूको 66% मा कुनै उपयोगी जानकारी समावेश थिएन र केवल विकासकर्ताहरूबाट समय लिइयो जुन उपयोगी कुरामा खर्च गर्न सकिन्छ।

विकासकर्ताहरू बेकार रिपोर्टहरू पार्सिङ गर्न र त्यहाँ धेरै पटक समावेश जानकारी दोहोरो-जाँच गर्न धेरै समय बर्बाद गर्न बाध्य छन्, किनकि डिजाइनको बाह्य गुणस्तरले जानकारीमा थप विश्वास सिर्जना गर्दछ र विकासकर्ताले केहि गलत बुझेको महसुस गर्दछ। अर्कोतर्फ, यस्तो रिपोर्ट उत्पन्न गर्न आवेदकबाट न्यूनतम प्रयास चाहिन्छ, जसले वास्तविक समस्याको लागि जाँच गर्न परेशान गर्दैन, तर केवल AI सहायकहरूबाट प्राप्त डाटालाई अन्धाधुन्ध प्रतिलिपि गर्दछ, पुरस्कार प्राप्त गर्न संघर्षमा भाग्यको आशा गर्दै।

त्यस्ता फोहोर रिपोर्टका दुई उदाहरणहरू दिइएका छन्। खतरनाक अक्टोबर जोखिम (CVE-2023-38545) को बारे मा जानकारी को योजनाबद्ध खुलासा को दिन अघि, एक रिपोर्ट Hackerone मार्फत पठाइएको थियो कि फिक्स संग प्याच सार्वजनिक रूपमा उपलब्ध भएको थियो। वास्तवमा, रिपोर्टमा समान समस्याहरू र गुगलको एआई सहायक बार्ड द्वारा संकलित विगतका कमजोरीहरूको बारेमा विस्तृत जानकारीको स्निपेटहरूको बारेमा तथ्यहरूको मिश्रण समावेश थियो। नतिजाको रूपमा, जानकारी नयाँ र सान्दर्भिक देखिन्थ्यो, र वास्तविकतासँग कुनै सम्बन्ध थिएन।

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

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

स्रोत: opennet.ru