AI ٹولز کے ذریعہ تیار کردہ خطرے کی رپورٹس کی وجہ سے مسائل

نیٹ ورک کرل پر ڈیٹا وصول کرنے اور بھیجنے کی افادیت کے مصنف ڈینیل اسٹین برگ نے کمزوری کی رپورٹس بناتے وقت AI ٹولز کے استعمال پر تنقید کی۔ اس طرح کی رپورٹس میں تفصیلی معلومات شامل ہوتی ہیں، عام زبان میں لکھی جاتی ہیں اور اعلیٰ معیار کی نظر آتی ہیں، لیکن حقیقت میں سوچ سمجھ کر تجزیہ کیے بغیر وہ صرف گمراہ کن ہو سکتی ہیں، حقیقی مسائل کی جگہ اعلیٰ معیار کے نظر آنے والے کوڑے کے مواد سے۔

Curl پروجیکٹ نئی کمزوریوں کی نشاندہی کرنے کے لیے انعامات ادا کرتا ہے اور اس سے پہلے ہی ممکنہ مسائل کی 415 رپورٹس موصول ہو چکی ہیں، جن میں سے صرف 64 کی کمزوریوں کے طور پر اور 77 کی غیر حفاظتی کیڑے کے طور پر تصدیق ہوئی ہے۔ اس طرح، تمام رپورٹس میں سے 66% میں کوئی مفید معلومات نہیں تھی اور صرف ڈویلپرز سے وقت نکالا جو کسی مفید چیز پر خرچ کیا جا سکتا تھا۔

ڈیولپرز بیکار رپورٹس کو پارس کرنے اور وہاں موجود معلومات کو کئی بار چیک کرنے میں کافی وقت ضائع کرنے پر مجبور ہیں، کیونکہ ڈیزائن کا بیرونی معیار معلومات میں اضافی اعتماد پیدا کرتا ہے اور یہ احساس ہوتا ہے کہ ڈویلپر کو کچھ غلط فہمی ہوئی ہے۔ دوسری طرف، ایسی رپورٹ تیار کرنے کے لیے درخواست دہندہ کی طرف سے کم سے کم محنت کی ضرورت ہوتی ہے، جو کسی حقیقی مسئلے کی جانچ پڑتال کرنے کی زحمت نہیں کرتا، بلکہ محض انعام حاصل کرنے کی جدوجہد میں قسمت کی امید کے ساتھ، AI معاونین سے موصول ہونے والے ڈیٹا کو آنکھیں بند کرکے کاپی کرتا ہے۔

اس طرح کی کوڑا کرکٹ کی دو مثالیں دی جاتی ہیں۔ خطرناک اکتوبر کے خطرے (CVE-2023-38545) کے بارے میں معلومات کے منصوبہ بند انکشاف سے ایک دن پہلے ہیکرون کے ذریعے ایک رپورٹ بھیجی گئی تھی کہ درست کرنے والا پیچ عوامی طور پر دستیاب ہو گیا ہے۔ درحقیقت، رپورٹ میں اسی طرح کے مسائل کے بارے میں حقائق اور ماضی کی کمزوریوں کے بارے میں تفصیلی معلومات کے ٹکڑوں کا مرکب تھا جسے گوگل کے AI اسسٹنٹ بارڈ نے مرتب کیا تھا۔ نتیجے کے طور پر، معلومات نئی اور متعلقہ لگ رہی تھی، اور حقیقت سے کوئی تعلق نہیں تھا.

دوسری مثال ویب ساکٹ ہینڈلر میں بفر اوور فلو کے بارے میں 28 دسمبر کو موصول ہونے والے ایک پیغام سے متعلق ہے، جو ایک صارف کی طرف سے بھیجا گیا ہے جس نے ہیکرون کے ذریعے خطرات کے بارے میں پہلے ہی مختلف منصوبوں کو آگاہ کیا تھا۔ مسئلہ کو دوبارہ پیش کرنے کے طریقہ کار کے طور پر، رپورٹ میں strcpy کے ساتھ نقل کرتے وقت استعمال ہونے والے بفر کے سائز سے بڑی قدر کے ساتھ ترمیم شدہ درخواست کو پاس کرنے کے بارے میں عمومی الفاظ شامل تھے۔ رپورٹ میں تصحیح کی ایک مثال بھی فراہم کی گئی ہے (strcpy کو strncpy سے تبدیل کرنے کی ایک مثال) اور کوڈ کی لائن "strcpy(keyval, randstr)" کے لنک کی نشاندہی کی گئی ہے، جس میں درخواست گزار کے مطابق، ایک غلطی تھی۔

ڈویلپر نے تین بار ہر چیز کو دو بار چیک کیا اور کوئی مسئلہ نہیں ملا، لیکن چونکہ رپورٹ اعتماد سے لکھی گئی تھی اور اس میں اصلاح بھی تھی، اس لیے ایسا محسوس ہوا کہ کہیں کچھ گم ہے۔ یہ واضح کرنے کی ایک کوشش کہ محقق کس طرح strcpy کال سے پہلے موجود واضح سائز کے چیک کو نظرانداز کرنے میں کامیاب ہوا اور کس طرح کیول بفر کا سائز پڑھنے والے ڈیٹا کے سائز سے کم نکلا جس سے تفصیلی، لیکن اضافی معلومات نہیں، وضاحتیں جو صرف بفر اوور فلو کی واضح عام وجوہات کو چباتا ہے جو مخصوص Curl کوڈ سے متعلق نہیں ہے۔ جوابات ایک AI اسسٹنٹ کے ساتھ بات چیت کی یاد تازہ کر رہے تھے، اور یہ جاننے کی بے مقصد کوششوں میں آدھا دن گزارنے کے بعد کہ مسئلہ خود کو کس طرح ظاہر کرتا ہے، آخر کار ڈویلپر کو یقین ہو گیا کہ حقیقت میں کوئی خطرہ نہیں ہے۔

ماخذ: opennet.ru

نیا تبصرہ شامل کریں