ບັນຫາເນື່ອງຈາກການລາຍງານຄວາມອ່ອນແອທີ່ກະກຽມໂດຍເຄື່ອງມື AI

Daniel Stenberg, ຜູ້ຂຽນປະໂຫຍດສໍາລັບການຮັບແລະສົ່ງຂໍ້ມູນຜ່ານເຄືອຂ່າຍ curl, ໄດ້ວິພາກວິຈານການນໍາໃຊ້ເຄື່ອງມື AI ໃນເວລາທີ່ສ້າງບົດລາຍງານຄວາມອ່ອນແອ. ບົດລາຍງານດັ່ງກ່າວປະກອບມີຂໍ້ມູນລະອຽດ, ຖືກຂຽນເປັນພາສາທໍາມະດາແລະເບິ່ງມີຄຸນນະພາບສູງ, ແຕ່ບໍ່ມີການວິເຄາະໃນຄວາມເປັນຈິງແລ້ວພວກເຂົາພຽງແຕ່ສາມາດເຂົ້າໃຈຜິດ, ແທນທີ່ບັນຫາທີ່ແທ້ຈິງດ້ວຍເນື້ອຫາຂີ້ເຫຍື້ອທີ່ມີຄຸນນະພາບ.

ໂຄງການ Curl ຈ່າຍໃຫ້ລາງວັນສໍາລັບການກໍານົດຈຸດອ່ອນໃຫມ່ແລະໄດ້ຮັບແລ້ວ 415 ບົດລາຍງານຂອງບັນຫາທີ່ອາດຈະເກີດຂຶ້ນ, ໃນນັ້ນມີພຽງແຕ່ 64 ໄດ້ຮັບການຢືນຢັນວ່າເປັນຊ່ອງໂຫວ່ແລະ 77 ເປັນແມງໄມ້ທີ່ບໍ່ແມ່ນຄວາມປອດໄພ. ດັ່ງນັ້ນ, 66% ຂອງບົດລາຍງານທັງຫມົດບໍ່ມີຂໍ້ມູນທີ່ເປັນປະໂຫຍດແລະພຽງແຕ່ໃຊ້ເວລາຈາກນັກພັດທະນາທີ່ສາມາດໃຊ້ເວລາໃນສິ່ງທີ່ມີປະໂຫຍດ.

ນັກພັດທະນາຖືກບັງຄັບໃຫ້ເສຍເວລາຫຼາຍໃນການວິເຄາະບົດລາຍງານທີ່ບໍ່ມີປະໂຫຍດແລະການກວດສອບຂໍ້ມູນທີ່ມີຢູ່ໃນນັ້ນຫຼາຍຄັ້ງ, ເພາະວ່າຄຸນນະພາບພາຍນອກຂອງການອອກແບບສ້າງຄວາມຫມັ້ນໃຈເພີ່ມເຕີມໃນຂໍ້ມູນແລະມີຄວາມຮູ້ສຶກວ່ານັກພັດທະນາເຂົ້າໃຈຜິດບາງສິ່ງບາງຢ່າງ. ໃນທາງກົງກັນຂ້າມ, ການສ້າງບົດລາຍງານດັ່ງກ່າວຮຽກຮ້ອງໃຫ້ມີຄວາມພະຍາຍາມຫນ້ອຍຈາກຜູ້ສະຫມັກ, ຜູ້ທີ່ບໍ່ໄດ້ລົບກວນການກວດສອບບັນຫາທີ່ແທ້ຈິງ, ແຕ່ພຽງແຕ່ຄັດລອກຂໍ້ມູນທີ່ໄດ້ຮັບຈາກຜູ້ຊ່ວຍ AI ໂດຍຕາບອດ, ຫວັງວ່າຈະມີໂຊກໃນການຕໍ່ສູ້ທີ່ຈະໄດ້ຮັບລາງວັນ.

ສອງຕົວຢ່າງຂອງບົດລາຍງານຂີ້ເຫຍື້ອດັ່ງກ່າວໄດ້ຖືກມອບໃຫ້. ມື້ກ່ອນການວາງແຜນການເປີດເຜີຍຂໍ້ມູນກ່ຽວກັບຊ່ອງໂຫວ່ເດືອນຕຸລາທີ່ເປັນອັນຕະລາຍ (CVE-2023-38545), ບົດລາຍງານໄດ້ຖືກສົ່ງຜ່ານ Hackerone ວ່າ patch ກັບການແກ້ໄຂໄດ້ກາຍເປັນສາທາລະນະ. ໃນຄວາມເປັນຈິງ, ບົດລາຍງານປະກອບດ້ວຍຂໍ້ເທັດຈິງທີ່ປະສົມປະສານກ່ຽວກັບບັນຫາທີ່ຄ້າຍຄືກັນແລະຂໍ້ມູນລາຍລະອຽດກ່ຽວກັບຈຸດອ່ອນທີ່ຜ່ານມາລວບລວມໂດຍຜູ້ຊ່ວຍ AI ຂອງ Google Bard. ດັ່ງນັ້ນ, ຂໍ້ມູນເບິ່ງຄືວ່າໃຫມ່ແລະມີຄວາມກ່ຽວຂ້ອງ, ແລະບໍ່ມີຄວາມກ່ຽວຂ້ອງກັບຄວາມເປັນຈິງ.

ຕົວຢ່າງທີສອງກ່ຽວຂ້ອງກັບຂໍ້ຄວາມທີ່ໄດ້ຮັບໃນວັນທີ 28 ເດືອນທັນວາກ່ຽວກັບ buffer overflow ໃນຕົວຈັດການ WebSocket, ສົ່ງໂດຍຜູ້ໃຊ້ທີ່ໄດ້ແຈ້ງໃຫ້ໂຄງການຕ່າງໆກ່ຽວກັບຄວາມອ່ອນແອຜ່ານ Hackerone. ເປັນວິທີການຜະລິດຄືນໃຫມ່ຂອງບັນຫາ, ບົດລາຍງານໄດ້ລວມເອົາຄໍາສັບທົ່ວໄປກ່ຽວກັບການສົ່ງຄໍາຮ້ອງຂໍດັດແກ້ທີ່ມີມູນຄ່າທີ່ໃຫຍ່ກວ່າຂະຫນາດຂອງ buffer ທີ່ໃຊ້ໃນເວລາທີ່ຄັດລອກດ້ວຍ strcpy. ບົດລາຍງານຍັງໄດ້ສະຫນອງຕົວຢ່າງຂອງການແກ້ໄຂ (ຕົວຢ່າງຂອງການປ່ຽນແທນ strcpy ກັບ strncpy) ແລະຊີ້ໃຫ້ເຫັນການເຊື່ອມຕໍ່ກັບເສັ້ນລະຫັດ "strcpy(keyval, randstr)", ເຊິ່ງ, ອີງຕາມຜູ້ສະຫມັກ, ມີຂໍ້ຜິດພາດ.

ນັກພັດທະນາໄດ້ກວດເບິ່ງທຸກຢ່າງສາມເທື່ອສອງຄັ້ງແລະບໍ່ພົບບັນຫາໃດໆ, ແຕ່ນັບຕັ້ງແຕ່ບົດລາຍງານໄດ້ຖືກຂຽນໄວ້ຢ່າງຫມັ້ນໃຈແລະເຖິງແມ່ນວ່າມີການແກ້ໄຂ, ມີຄວາມຮູ້ສຶກວ່າບາງສິ່ງບາງຢ່າງຫາຍໄປບາງບ່ອນ. ຄວາມພະຍາຍາມເພື່ອຄວາມກະຈ່າງແຈ້ງວິທີການທີ່ນັກຄົ້ນຄວ້າໄດ້ຈັດການເພື່ອຂ້າມການກວດສອບຂະຫນາດທີ່ຊັດເຈນກ່ອນທີ່ຈະໂທຫາ strcpy ແລະຂະຫນາດຂອງ keyval buffer ໄດ້ກາຍເປັນຫນ້ອຍກ່ວາຂະຫນາດຂອງຂໍ້ມູນທີ່ອ່ານໄດ້ນໍາໄປສູ່ລາຍລະອຽດ, ແຕ່ບໍ່ໄດ້ປະຕິບັດຂໍ້ມູນເພີ່ມເຕີມ, ຄໍາອະທິບາຍ. ທີ່ພຽງແຕ່ chewed ກ່ຽວກັບສາເຫດທົ່ວໄປທີ່ຈະແຈ້ງຂອງການ overflow buffer ບໍ່ກ່ຽວຂ້ອງກັບລະຫັດ Curl ສະເພາະ. ຄໍາຕອບແມ່ນ reminiscent ຂອງການສື່ສານກັບ AI ຜູ້ຊ່ວຍ, ແລະຫຼັງຈາກໃຊ້ເວລາເຄິ່ງມື້ໃນຄວາມພະຍາຍາມທີ່ບໍ່ມີຈຸດຫມາຍທີ່ຈະຊອກຫາວິທີການທີ່ບັນຫາສະແດງໃຫ້ເຫັນຕົວຂອງມັນເອງ, ໃນທີ່ສຸດຜູ້ພັດທະນາໄດ້ຫມັ້ນໃຈວ່າໃນຄວາມເປັນຈິງບໍ່ມີຊ່ອງໂຫວ່.

ແຫຼ່ງຂໍ້ມູນ: opennet.ru