เบื้องหลังการเสริมความปลอดภัยให้ Firefox ด้วย Claude Mythos Preview

 (hacks.mozilla.org)
5 คะแนน โดย GN⁺ 2026-05-08 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • Mozilla ได้สร้างไปป์ไลน์สำหรับค้นหาบั๊กความปลอดภัยจริงใน Firefox ในวงกว้าง โดยยกระดับประสิทธิภาพของโมเดลและปรับปรุง harness เพื่อเพิ่มสัญญาณและลดสัญญาณรบกวนในรายงานความปลอดภัยที่สร้างโดย AI
  • ใน Firefox 150 release มีการแก้ไขบั๊ก 271 รายการที่ Claude Mythos Preview ระบุพบ และยังมีการแก้ไขที่เกี่ยวข้องรวมอยู่ใน 149.0.2, 150.0.1, 150.0.2 ด้วย
  • บั๊กเด่นที่เปิดเผยมีทั้ง primitive ของ fake object จากการลบการ initializе โครงสร้าง WebAssembly GC ใน JIT, parent process UAF ผ่าน race condition ของ IPC, ปัญหา NaN deserialization, บั๊ก rehash ใน XSLT ที่มีมานาน 20 ปี, และ 16-bit layout bitfield overflow ที่ใช้ rowspan=0
  • บั๊กที่เปิดเผยจำนวนมากเป็น การหลบหนี sandbox โดยตั้งอยู่บนสมมติฐานว่ามี content process ที่ถูกเจาะแล้วและยกระดับสิทธิ์ไปยัง parent process ที่มีสิทธิ์สูงกว่า ทำให้ AI analysis ครอบคลุมพื้นผิวการโจมตีที่ fuzzing เพียงอย่างเดียวค้นหาได้ยากกว่า
  • Mozilla วาง agentic harness ทับบนโครงสร้างพื้นฐาน fuzzing เดิม เพื่อตัดการคาดเดาที่พิสูจน์ซ้ำไม่ได้ทิ้ง และตรวจสอบสมมติฐานด้วย test case โดยมีแผนจะผนวกเข้ากับ continuous integration เพื่อสแกนแพตช์เมื่อถูกรวมเข้า tree ต่อไป

การเปลี่ยนแปลงของบั๊กความปลอดภัยใน Firefox ที่ AI model เปิดเผย

  • จนถึงไม่กี่เดือนก่อน รายงานบั๊กความปลอดภัยที่สร้างโดย AI ซึ่งส่งเข้ามายังโครงการโอเพนซอร์สมักดูน่าเชื่อถือแต่ผิดพลาดบ่อย ทำให้ผู้ดูแลต้องแบกรับ ต้นทุนที่ไม่สมมาตร
  • แต่ใน Firefox สถานการณ์เปลี่ยนไปมากในช่วงเวลาสั้น ๆ โดยสาเหตุหลักคือประสิทธิภาพของโมเดลที่ดีขึ้น และเทคนิคที่ดีขึ้นในการควบคุม ขยาย และผสานโมเดลด้วย harness เพื่อเพิ่มสัญญาณและกรองสัญญาณรบกวน
  • ปกติแล้ว Mozilla จะยังไม่เปิดเผยรายงานบั๊กแบบละเอียดอีกหลายเดือนแม้ออกคำแนะนำด้านความปลอดภัยและแพตช์ไปแล้ว แต่ครั้งนี้ได้ตัดสินใจเปิดเผยรายงานบางส่วนโดยคำนึงถึงความเร่งด่วนและความสนใจของทั้ง ecosystem
  • รายงานที่เปิดเผยคัดมาจากหลาย subsystem ของเบราว์เซอร์ แม้การคัดเลือกจะค่อนข้างสุ่มอยู่บ้าง แต่ความลึกและความหลากหลายของรายงานแสดงให้เห็นว่าฝ่ายป้องกันจำเป็นต้องนำเทคนิคนี้ไปใช้

บั๊กเด่นที่เปิดเผย

  • 2024918
    • เนื่องจากการตรวจสอบความเท่ากันที่ผิดพลาด JIT จึงตัดการ initializе โครงสร้าง WebAssembly GC ที่ยังมีชีวิตอยู่ทิ้งระหว่าง optimization และทำให้สร้าง primitive ของ fake object ที่เชื่อมโยงไปสู่การอ่าน/เขียนแบบ arbitrary ที่อาจเกิดขึ้นได้ในโค้ดที่ผ่านการ fuzzing อย่างหนักจากทั้งนักวิจัยภายในและภายนอก
  • 2024437
    • บั๊กใน <legend> ที่มีมานาน 15 ปี ซึ่งถูกกระตุ้นได้ด้วยการผสม edge case จากส่วนที่ห่างกันของเบราว์เซอร์อย่างละเอียด ทั้งข้อจำกัดความลึกของ recursive stack, expando property และ cycle collection
  • 2021894
    • สามารถ exploit race condition ของ IPC ได้อย่างเสถียร ทำให้ content process ที่ถูกเจาะแล้วจัดการ reference count ของ IndexedDB ใน parent process ได้ และก่อให้เกิด UAF กับ การหลบหนี sandbox ที่เป็นไปได้
  • 2022034
    • raw NaN สามารถข้ามขอบเขตของ IPC แล้วดูเหมือน tagged JS object pointer ได้ ทำให้การ deserialization ของ double อาจนำไปสู่ primitive ของ fake object ใน parent process และการหลบหนี sandbox
  • 2024653
    • test case ที่ซับซ้อนซึ่งผูก nested event loop, listener ของ pagehide และ garbage collection เข้าด้วยกัน ทำให้เกิด UAF ใน property setter ขององค์ประกอบ <object>
  • 2022733
    • อัด certificate hash หลายพันรายการเข้าไปใน WebTransport เพื่อเพิ่ม race condition ในลูปคัดลอกที่มี reference count หนาแน่น และทำให้เกิด parent UAF ผ่าน IPC จาก content process ที่ถูกเจาะแล้ว
  • 2023958
    • ดักจับการเรียกฟังก์ชัน DNS ของ glibc เพื่อจำลอง DNS server ที่เป็นอันตราย และจำลอง fallback edge case จาก UDP ไป TCP จนก่อให้เกิด buffer over-read และการรั่วไหลของหน่วยความจำบนสแตกของ parent process ระหว่างการ parse HTTPS RR และ ECH
  • 2025977
    • บั๊ก XSLT ที่มีมานาน 20 ปี โดยการเรียก key() แบบ reentrant ทำให้เกิดการ rehash ของ hash table และปล่อย backing store แต่ยังคงใช้ raw entry pointer ต่อไป และเป็นหนึ่งในหลายปัญหา XSLT ระดับ sec-high ที่ได้รับการแก้ไข
  • 2027298
    • หลังจากแพตช์ color picker เพื่อจำลองการเลือกของผู้ใช้ที่ยากต่อการทำอัตโนมัติแล้ว ระบบได้ใช้ synchronous input event เพื่อหมุน nested event loop, re-enter actor teardown และทำให้ callback ถูกปล่อยระหว่างที่กำลัง unroll จนเกิด content process UAF
  • 2023817
    • content process ที่ถูกเจาะแล้วสามารถส่งภาพวอลเปเปอร์ใดก็ได้ให้ parent process ถอดรหัส และเมื่อจับคู่กับช่องโหว่สมมุติใน image decoder ก็อาจนำไปสู่การหลบหนี sandbox ได้
    • ต้องอาศัยการอนุมานที่ทำอัตโนมัติได้ยากเพื่อพิจารณาระดับความน่าเชื่อถือของอินพุตใน parent process
  • 2029813
    • ใน RLBox ซึ่งเป็นเทคโนโลยี sandboxing แบบละเอียดใน Firefox 95 มีการหลบเลี่ยง sandbox โดยอาศัยช่องโหว่ในตรรกะการตรวจสอบที่ใช้คัดลอกค่าจากฝั่งที่ไม่น่าเชื่อถือไปยังฝั่งที่เชื่อถือได้
  • 2026305
    • test case ขนาดเล็กมากที่ใช้ความหมายพิเศษของ rowspan=0 ในตาราง HTML โดยเพิ่มแถวมากกว่า >65535 แถวเพื่อหลบการ clamping และทำให้ 16-bit layout bitfield overflow ซึ่งไม่ถูก fuzzers จับพบมาหลายปี

การหลบหนี sandbox และชั้นการป้องกัน

  • บั๊กที่เปิดเผยจำนวนมากเป็น การหลบหนี sandbox และหากจะนำไปสู่การเจาะระบบทั้งเชนของ Firefox ก็ต้องจับคู่กับ exploit อื่นเพิ่มเติม
  • รายงานประเภทนี้ตั้งอยู่บนสมมติฐานว่า sandboxed process ที่ใช้ render เนื้อหาเว็บไซต์ถูกเจาะจากบั๊กอื่นไปแล้ว และโค้ด machine code ที่ผู้โจมตีควบคุมได้กำลังพยายามยกระดับสิทธิ์ไปยัง parent process ที่มีสิทธิ์สูงกว่า
  • เมื่อสร้างการหลบหนี sandbox โมเดลสามารถแพตช์ซอร์สโค้ด Firefox ได้ตราบใดที่โค้ดที่แก้ไขนั้นทำงานอยู่ภายใน sandboxed process เท่านั้น
  • บั๊กประเภทนี้ค้นหาด้วย fuzzing ได้ยาก และ Mozilla ก็พัฒนาเทคนิคอย่าง snapshot-based IPC fuzzing มาแล้ว แต่ AI analysis สามารถครอบคลุมพื้นผิวสำคัญนี้ได้ครอบคลุมกว่ามาก
  • สิ่งที่โมเดลหาไม่พบก็มีความสำคัญเช่นกัน
    • ตลอดหลายปีที่ผ่านมา นักวิจัยด้านความปลอดภัยได้ส่งรายงานหลายฉบับที่ก่อ prototype pollution ใน parent process ที่มีสิทธิ์สูง เพื่อหลบหนี process sandbox
    • แทนที่ Mozilla จะแก้ทีละปัญหา ก็ได้ใช้ การเปลี่ยนแปลงเชิงสถาปัตยกรรม ที่ทำให้ prototype ถูก freeze โดยปริยาย
    • ใน log ของ harness มีร่องรอยจำนวนมากที่พยายามเส้นทางการหลบหนีนี้แต่ถูกการออกแบบขวางไว้ ซึ่งยืนยันผลโดยตรงของงาน hardening ก่อนหน้า

สร้างไปป์ไลน์เสริมความปลอดภัยด้วย harness

  • ในช่วงไม่กี่ปีที่ผ่านมา Mozilla ได้ทดลองภายในเรื่อง LLM code auditing เพื่อวิเคราะห์แบบ static กับโค้ดความเสี่ยงสูง โดยใช้โมเดลอย่าง GPT 4 หรือ Sonnet 3.5
  • การทดลองช่วงแรกแสดงให้เห็นถึงศักยภาพ แต่มีสัดส่วน false positive สูงจนขยายสเกลได้ยาก
  • สถานการณ์เปลี่ยนไปเมื่อมี agentic harness ที่สามารถตรวจจับปัญหาความปลอดภัยได้อย่างเสถียร
    • สามารถพบบั๊กจริงได้
    • สามารถทิ้งการคาดเดาที่พิสูจน์ซ้ำไม่ได้
    • หากมีอินเทอร์เฟซและคำสั่งที่เหมาะสม ก็สามารถสร้างและรัน test case ที่ทำซ้ำได้เพื่อยืนยันสมมติฐานเกี่ยวกับบั๊กในโค้ดแบบ dynamic
  • หลังแก้ไข issue เบื้องต้นที่ Anthropic ส่งมา ในเดือนกุมภาพันธ์ Mozilla ก็ได้สร้าง harness ของตนเองบน โครงสร้างพื้นฐาน fuzzing เดิม
  • ในช่วงแรก มีการเริ่มทดลองขนาดเล็กโดยใช้ Claude Opus 4.6 เพื่อค้นหาการหลบหนี sandbox
    • เพียงโมเดลนี้โมเดลเดียวก็ระบุช่องโหว่ที่ไม่เคยทราบมาก่อนจำนวนมาก ซึ่งต้องอาศัยการให้เหตุผลซับซ้อนกับโค้ดเอนจินเบราว์เซอร์แบบหลายโปรเซส
    • ช่วงแรกทีมเฝ้าดูกระบวนการโดยตรงผ่านเทอร์มินัล และปรับ prompt กับ logic แบบเรียลไทม์
    • เมื่อการทำงานเริ่มเสถียรแล้ว จึงทำงานขนานบน ephemeral VM หลายตัว โดยให้แต่ละ VM ค้นหาบั๊กในไฟล์เป้าหมายเฉพาะ และบันทึกผลลง bucket
  • แต่เพียงแค่ระบุ subsystem ที่พบปัญหายังไม่เพียงพอ
    • ต้องผสานเข้ากับ วงจรชีวิตบั๊กความปลอดภัย ทั้งหมด รวมถึงจะหาอะไร ดูตรงไหน และจัดการผลลัพธ์อย่างไร
    • รวมถึงการตัดความซ้ำกับ issue เดิม, การติดตามบั๊ก, triage และการออกแพตช์แก้ไข
    • โมเดลเป็น primitive แกนกลางที่ขับเคลื่อน harness แต่ถ้าจะทำให้มีประโยชน์ในระดับใหญ่จำเป็นต้องมีทั้งไปป์ไลน์ครบชุด
  • harness อาจนำกลับใช้ซ้ำข้ามโครงการได้ แต่ไปป์ไลน์จะแตกต่างกันไปตามความหมายของ codebase, เครื่องมือ และกระบวนการของแต่ละโครงการ
  • ต้องมี feedback loop ที่แน่นแฟ้นกับกระบวนการที่วิศวกร Firefox ใช้จัดการบั๊กที่ไหลเข้ามา และต้องอาศัยการทำซ้ำอย่างมาก

Claude Mythos Preview และผลของการเปลี่ยนโมเดล

  • เมื่อมีไปป์ไลน์แบบ end-to-end แล้ว การสลับไปใช้โมเดลอื่นเมื่อมีโมเดลใหม่ออกมาก็ทำได้ง่าย
  • Mozilla พบ serious bug หลายรายการจากโมเดลแบบเปิดเช่นกัน และด้วยไปป์ไลน์นี้ เมื่อมีโอกาสประเมิน Claude Mythos Preview ก็สามารถนำมาใช้งานได้ทันที
  • การอัปเกรดโมเดลเพิ่มประสิทธิผลของทั้งไปป์ไลน์
    • หาบั๊กที่เป็นไปได้ได้ดีขึ้น
    • สร้าง proof-of-concept test case เพื่อพิสูจน์บั๊กได้ดีขึ้น
    • สรุปพยาธิสภาพและผลกระทบได้ดีขึ้น
  • นอกจากการแก้ไขบั๊ก 271 รายการที่ Claude Mythos Preview ระบุพบใน Firefox 150 release แล้ว ยังมีการแก้ไขที่เกี่ยวข้องใน 149.0.2, 150.0.1, 150.0.2 ด้วย
  • ภายในองค์กรยังคงค้นหาบั๊กด้วยวิธีอื่นอย่างต่อเนื่อง และเช่นเดียวกับโครงการอื่น ๆ รายงานจากภายนอกก็เพิ่มขึ้นมากในช่วงไม่กี่เดือนที่ผ่านมา
  • ทุกบั๊กต้องอาศัยความใส่ใจอย่างมากเพื่อแก้ให้ถูกต้อง และเพื่อไล่ให้ทันสเกลที่ไม่เคยมีมาก่อน ในช่วงหลายเดือนที่ผ่านมาได้มีงานหนักและชั่วโมงทำงานยาวนานจำนวนมาก
  • มีผู้คนมากกว่า 100 คนร่วมมีส่วนต่อโค้ดเพื่อส่งมอบ Firefox ที่ปลอดภัยที่สุด ไม่เพียงแต่การเขียนและรีวิวแพตช์ แต่ยังรวมถึงการสร้างและขยายไปป์ไลน์, triage, ทดสอบแพตช์แก้ไข และบริหารกระบวนการออกรีลีสของแต่ละบั๊ก

บทเรียนสำคัญ

  • ทุกคนที่สร้างซอฟต์แวร์สามารถใช้โมเดลสมัยใหม่และ harness เพื่อค้นหาบั๊กและเสริมความแข็งแกร่งให้โค้ดได้ตั้งแต่ตอนนี้
  • สามารถเริ่มจาก prompt ง่าย ๆ แล้วสังเกตและทำซ้ำได้
    • prompt แรกเริ่มไม่ได้แตกต่างจากวิธีในวิดีโอนี้มากนัก
    • แม้จะมีการเพิ่ม orchestration และเครื่องมือจำนวนมากเพื่อปรับแต่งและขยายไปป์ไลน์ผ่านการทำซ้ำ แต่แก่นของลูปภายในคือ “มีบั๊กอยู่ในโค้ดส่วนนี้ จงหาให้พบและสร้าง test case”
  • Firefox ยังไม่ได้ขุดค้นบั๊กที่อาจมีอยู่จนหมด แต่ก็พอใจกับทิศทางในปัจจุบัน
  • การสแกนในตอนนี้ยังเน้นพื้นที่โค้ดเฉพาะที่กำหนดไว้ เช่น ไฟล์และฟังก์ชัน โดยอาศัยทั้งการตัดสินใจของมนุษย์และสัญญาณอัตโนมัติผสมกัน
  • ในอนาคตอันใกล้มีแผนจะผนวกการวิเคราะห์นี้เข้ากับระบบ continuous integration เพื่อสแกนแพตช์เมื่อถูกรวมเข้า tree
  • โมเดลตอบสนองต่อรูปแบบบริบทที่ให้มาได้ยืดหยุ่น และคาดว่าการสแกนแบบอิงแพตช์จะทำงานได้ดีพอ ๆ กับหรือดีกว่าการสแกนแบบอิงไฟล์
  • ช่วงเวลานี้มีทั้งความเสี่ยงและโอกาสอย่างมาก และทุกฝ่ายควรขยับไปด้วยกันเพื่อทำให้อินเทอร์เน็ตปลอดภัยขึ้น

คำถามที่พบบ่อย

  • เหตุใดจำนวน “271 บั๊ก” จึงต่างจากตัวเลขในคำแนะนำด้านความปลอดภัย

    • ใน หน้าเว็บคำแนะนำด้านความปลอดภัย Mozilla จัดกลุ่มบั๊กที่รายงานภายในหลายรายการไว้เป็น CVE แบบ “rollup” ที่มีหลายบั๊กอยู่ข้างใต้
    • หน้าเว็บนี้สร้างจากไฟล์ yaml ใน repository foundation-security-advisories ซึ่งเป็นที่อย่างเป็นทางการสำหรับการกำหนด CVE
    • เบราว์เซอร์บางตัวไม่สร้างตัวระบุ CVE สำหรับปัญหาที่ค้นพบภายใน แต่ Mozilla เปิดเผยข้อมูลเหล่านี้เพื่อความโปร่งใสมากที่สุด
    • ใน Firefox 150 มี internal rollup 3 รายการ
      • CVE-2026-6784: 154 บั๊ก
      • CVE-2026-6785: 55 บั๊ก
      • CVE-2026-6786: 107 บั๊ก
    • ผลรวมของสาม internal rollup คือ 316 บั๊ก ซึ่งมากกว่า 271 บั๊กที่ประกาศว่าพบด้วย Claude Mythos Preview
    • เหตุผลคือทีมความปลอดภัยของ Mozilla โจมตี Firefox ทุกวันเพื่อค้นหาบั๊กใหม่ โดยใช้ทั้งระบบ fuzzing, การตรวจแบบแมนนวล และไปป์ไลน์ agentic ใหม่ที่ใช้หลายโมเดลร่วมกัน
    • ในรีลีสเดือนเมษายนมีการแก้ไขบั๊กความปลอดภัยทั้งหมด 423 รายการ
      • 271 บั๊กที่ประกาศไปเมื่อ 2 สัปดาห์ก่อน
      • บั๊กที่รายงานจากภายนอก 41 รายการ
      • อีก 111 รายการที่เหลือเป็นการค้นพบภายใน และแบ่งคร่าว ๆ ได้เป็นสามกลุ่ม
        • บั๊กที่พบด้วยไปป์ไลน์นี้โดยใช้ Claude Mythos Preview แต่แก้ไขในรีลีสอื่นที่ไม่ใช่ Firefox 150
        • บั๊กที่พบด้วยไปป์ไลน์นี้แต่ใช้โมเดลอื่น
        • บั๊กที่พบด้วยเทคนิคอื่น เช่น fuzzing
    • Anthropic ได้รับเครดิตโดยตรงสำหรับ CVE 3 รายการแยกจากงานล่าสุดนี้
      • CVE-2026-6746
      • CVE-2026-6757
      • CVE-2026-6758
    • ทั้งหมดนี้คือการแก้ไขบั๊กที่ Anthropic Frontier Red Team ส่งให้ Mozilla เมื่อหลายเดือนก่อน และแต่ละรายการได้รับ CVE เฉพาะตามกระบวนการปกติ

  • ความหมายของระดับความรุนแรงด้านความปลอดภัย

    • Mozilla ใช้ security severity ratings ตั้งแต่ critical ถึง low เพื่อบอกความเร่งด่วนของบั๊ก
    • sec-critical และ sec-high ใช้กับช่องโหว่ที่สามารถถูกกระตุ้นได้จากพฤติกรรมผู้ใช้ทั่วไป เช่น การเข้าเว็บไซต์
    • ไม่มีความแตกต่างทางเทคนิคระหว่าง sec-critical กับ sec-high แต่ sec-critical ใช้เฉพาะกับปัญหาที่เปิดเผยสู่สาธารณะแล้วหรือทราบว่าถูกใช้โจมตีจริง
    • sec-moderate ใช้กับช่องโหว่ที่เดิมอาจถูกประเมินเป็น sec-high แต่ต้องอาศัยขั้นตอนที่ผิดปกติและซับซ้อนจากฝั่งเหยื่อ
    • sec-low ใช้กับบั๊กกวนใจที่ห่างไกลจากอันตรายต่อผู้ใช้ เช่น crash ที่ปลอดภัย
    • ระดับของบั๊ก 271 รายการที่ประกาศใน Firefox 150 มีดังนี้
      • sec-high 180 รายการ
      • sec-moderate 80 รายการ
      • sec-low 11 รายการ
    • แม้ Mozilla จะให้ความสำคัญสูงสุดกับบั๊ก critical/high แต่ก็มักให้ความสำคัญกับบั๊กความปลอดภัยระดับ moderate และ low ด้วยเพื่อแก้ปัญหาความถูกต้องและเพิ่มการป้องกันเชิงลึก

  • ความต่างระหว่าง sec-high หรือ sec-critical กับ exploit จริง

    • บั๊ก sec-high หรือ sec-critical ไม่ได้แปลว่าเป็น exploit ที่ใช้งานได้จริงในทันที
    • ในกรณีส่วนใหญ่ บั๊ก critical/high เพียงรายการเดียวไม่เพียงพอที่จะเจาะ Firefox ได้
    • Firefox มีสถาปัตยกรรมการป้องกันเชิงลึก ดังนั้นแม้ exploit บั๊ก JIT ได้ ก็อาจได้เพียง remote code execution ภายใน process ที่ถูก sandbox และแยกตามเว็บไซต์
    • โดยทั่วไปผู้โจมตีจริงต้องเชื่อม exploit หลายรายการเข้าด้วยกัน เพื่อข้ามชั้น sandbox หนึ่งชั้นหรือมากกว่า และมาตรการลดความเสี่ยงระดับระบบปฏิบัติการ เช่น ASLR เพื่อยกระดับสิทธิ์
    • โดยทั่วไป Mozilla จะไม่สร้าง exploit เพื่อยืนยันว่าบั๊กสามารถถูกใช้โดยผู้โจมตีจริงได้หรือไม่
    • การจัดประเภท sec-high อิงจากอาการ crash ที่คาดการณ์ได้ เช่น use-after-free หรือปัญหาหน่วยความจำ out-of-bounds ที่ AddressSanitizer รายงาน
    • แบบจำลองภัยคุกคามตั้งสมมติฐานว่าหากทุ่มความพยายามเพียงพอ บั๊กเหล่านี้อาจถูกใช้โจมตีได้
    • แนวทางนี้ช่วยลดความเสี่ยงของ false negative ในการวิเคราะห์ความสามารถในการ exploit และทำให้สามารถทุ่มทรัพยากรไปกับการค้นหาและแก้ไขช่องโหว่ได้มากขึ้น

บทความที่เกี่ยวข้อง

2 ความคิดเห็น

 
GN⁺ 2026-05-09
ความคิดเห็นจาก Hacker News

  • ขอย้ำอีกครั้งว่า บั๊กก็คือบั๊ก “ช่องโหว่ที่อาจเป็นไปได้” ก็เป็นบั๊กเช่นกัน และช่องโหว่ต้องมีการยืนยันผลกระทบด้านความปลอดภัยด้วยการพิสูจน์แนวคิดหรือหลักฐานในระดับใกล้เคียงกัน
    คำพูดสำคัญ และบั๊กก็สำคัญ การแก้บั๊กจำนวนมากเป็นเรื่องสำคัญมาโดยตลอดและก็เป็นสิ่งที่ทำกันมาจริง ๆ ซึ่งแค่นั้นเองก็น่าประทับใจพอแล้ว
    Mythos ไม่ได้เขียนการพิสูจน์แนวคิดสำหรับช่องโหว่ทั้ง 271 รายการและไม่ได้พิสูจน์ว่ามีเส้นทางโค้ดที่เข้าถึงได้ซึ่งมีผลกระทบด้านความปลอดภัย Mythos พบ บั๊กที่ใช้ได้จริง 271 รายการ และผมคิดว่าแค่นั้นก็เพียงพอแล้ว

    • นิยามค่อนข้างชวนสับสนอยู่บ้าง แต่ Mozilla แบ่ง “บางอย่าง” ทั้ง 271 รายการนั้นไว้แบบนี้ [1]
      เพื่อเพิ่มบริบท Mozilla ใช้ระดับความรุนแรงด้านความปลอดภัยตั้งแต่ critical ถึง low เพื่อบอกความเร่งด่วนของบั๊ก โดย sec-critical และ sec-high ใช้กับช่องโหว่ที่ถูกกระตุ้นได้จากพฤติกรรมผู้ใช้ทั่วไป เช่น การเข้าเว็บเพจ และในทางเทคนิคไม่ได้แยกสองอย่างนี้ออกจากกัน แต่ sec-critical สงวนไว้สำหรับปัญหาที่เปิดเผยสู่สาธารณะแล้วหรือทราบว่าถูกใช้โจมตีจริง
      sec-moderate เดิมทีเข้าข่าย sec-high แต่ใช้กับช่องโหว่ที่ต้องอาศัยขั้นตอนผิดปกติและซับซ้อนจากฝั่งเหยื่อ ส่วน sec-low ใช้กับบั๊กกวนใจที่ห่างไกลจากการทำอันตรายผู้ใช้ เช่น การแครชอย่างปลอดภัย
      จากบั๊ก 271 รายการที่ประกาศใน Firefox 150 มี 180 รายการเป็น sec-high, 80 รายการเป็น sec-moderate และ 11 รายการเป็น sec-low
      Mozilla ยังใช้คำว่า “vulnerability” กับ sec-high ทั้งที่บรรทัดถัดลงมาก็บอกว่าไม่ได้หมายถึง practical exploit โดยตรง และในหน้าคำนิยามยังจัดแม้แต่ sec-low เป็น “vulnerabilities” ด้วย [2]
      คำเป็นเครื่องมือ และประโยชน์ของมันมาจากความหมายร่วมกัน ผมสงสัยว่าระบบความหมายนั้นไปรับมาจากไหน และสอดคล้องกับ Mozilla หรือแตกต่างกันอย่างไร
      [1] https://hacks.mozilla.org/2026/05/behind-the-scenes-hardenin...
      [2] https://wiki.mozilla.org/Security_Severity_Ratings/Client
    • จริง ๆ แล้ว Mythos ได้เขียนการพิสูจน์แนวคิดสำหรับบั๊กทุกตัวที่แครชจาก การละเมิดความปลอดภัยของหน่วยความจำ เช่น use-after-free และการอ่าน/เขียนนอกขอบเขต
      ตามมาตรฐานของเรา ถ้าไม่มีหลักฐานโต้แย้ง ระดับนี้ก็ถือเป็นหลักฐานเชิงปฏิบัติเพียงพอที่จะมองว่าเป็นช่องโหว่ด้านความปลอดภัย และเราก็ปฏิบัติกับบั๊กจากการ fuzz แบบนั้นมาโดยตลอด
    • Claude สามารถสร้าง PoC exploit สำหรับบั๊กที่นำไปใช้โจมตีได้ที่มันพบ และก็ทำได้จริง หากมันเชื่อว่าผู้ใช้เป็นเจ้าของโค้ดนั้น
      แหล่งข้อมูลมีแค่ประสบการณ์ส่วนตัวของผม และไม่สามารถแชร์หลักฐานได้
    • ในสถานการณ์ที่ต้องตัดสินใจว่าจะจัดการอะไรก่อน ความแตกต่างแบบนี้ใช้การไม่ได้
    • ถ้าไม่ใช่ “PoC 271 รายการสำหรับช่องโหว่” คำที่คุณน่าจะหาอยู่คงใกล้กับ exploit มากกว่า

  • ตอนแรกผมมองโพสต์บล็อกที่ไม่เชิงเทคนิคนั้นว่าเป็นโฆษณาสินค้าแบบโจ่งแจ้งให้ Anthropic ส่วนบทความ Mozilla Hacks ที่ลิงก์มานั้นเป็นแหล่งข้อมูลที่ดีกว่าบทความนี้และน่ายินดีที่มีการเปิดเผยออกมา
    ตอนนี้ดูยากที่จะปฏิเสธแล้วว่ามันมี ผลงานจริง อยู่บ้าง นิยามคำว่า “ช่องโหว่” ภายในของ Mozilla ดูจะกว้างกว่าที่หลายคนเข้าใจโดยสัญชาตญาณ แต่ก็ดีแล้วที่ปัญหาแบบนี้ถูกมองอย่างจริงจังและได้รับการแก้ไข

    • https://hacks.mozilla.org/2026/05/behind-the-scenes-hardenin...
    • ขณะเดียวกันบริษัทอื่นอย่าง AISLE ก็หาช่องโหว่แบบใกล้เคียงกับ Mythos ได้ด้วยโมเดลที่เก่ากว่าและ harness ของตัวเองเช่นกัน: https://aisle.com/blog/aisle-matches-anthropic-mythos-on-fre...
      Mythos เป็นของจริงก็จริง แต่ก็ดูเหมือนว่าคงทำแบบเดียวกันได้ด้วย Deepseek pro หรือ GPT 5.5

  • แหล่งต้นทาง: https://news.ycombinator.com/item?id=48051079
    อันนี้ดีกว่าเพราะมีการไล่รายการบางส่วนของรายงาน Bugzilla ที่เปิดเผยจริงด้วย หัวข้อนี้เคยถูกคุยไปครั้งหนึ่งก่อนหน้านี้ แต่ส่วนที่ว่ามีการเปิดรายงานบั๊กนั้นใหม่ทั้งหมด
    การสนทนาก่อนหน้านี้คือเมื่อ 2 สัปดาห์ก่อน มี 36 คอมเมนต์: https://news.ycombinator.com/item?id=47885042

  • หวังว่าสักวัน LLM จะเก่งในการหาบั๊กและแก้บั๊กมากพอจนวิศวกร Firefox โฟกัสได้แค่ การเพิ่มฟีเจอร์ใหม่
    ไม่ได้ประชดนะ Firefox สมควรถูกใช้งานมากกว่านี้ คนรอบตัวผมส่วนใหญ่ไม่ใช้ Firefox เพราะ “Chrome ทำแทบทุกอย่างได้ดีกว่า” และ Firefox ก็แข่งกับโรดแมปของเบราว์เซอร์อื่นได้ยาก

    • เห็นด้วยเต็มที่ว่า Firefox ควรถูกใช้มากกว่านี้ ถึงขั้นที่เวลาซื้อของจากเว็บ ผมยังเลือกว่าจะซื้อจากที่ไหนโดยดูจากว่า ใช้งานบน Firefox ได้ไหม
      บางครั้งผมก็เขียนไปหาทีมซัพพอร์ตว่า Firefox ไม่ได้รับการรองรับหรือฟังก์ชันทำงานไม่ถูกต้อง ซึ่งแทบไม่เคยเกิดอะไรขึ้นเลย แต่รู้สึกว่านั่นคือสิ่งที่พอจะทำได้เพื่อให้เบราว์เซอร์นี้ยังอยู่ในสายตาผู้คน
    • ส่วนหนึ่งของปัญหาคือ ถ้าหยุดแก้บั๊ก Mozilla ก็มักจะไปทำ อะไรสไตล์ Mr Robot แทน เราแค่อยากได้เว็บเบราว์เซอร์ ไม่มีใครขอ Pocket หรือ AI
      ถ้า AI มาแก้บั๊กทั้งหมดให้แล้ว จะเหลืองานอะไรนอกจากรักษาความเข้ากันได้ของไวยากรณ์กับหลายภาษาในการ build? สุดท้ายก็คงวนกลับไปทำเบราว์เซอร์ให้เละอีกอยู่ดี
    • ผมสงสัยว่าคุณภาพและความพร้อมใช้งานแบบนั้นจะยิ่งทำให้ Chrome ทิ้งห่าง Firefox เร็วขึ้นอีกหรือเปล่า
      ถ้า Mozilla สร้าง LLM หรือ harness แบบปิดที่ใช้กันเฉพาะภายในแล้วแซง Chrome ได้ก็อีกเรื่อง แต่ในทางปฏิบัติมันก็ดูไม่ค่อยเป็นไปได้
    • Chrome ไม่ได้ดีกว่าอย่างมีนัยสำคัญในกรณีใช้งานเกิน 99% ด้วยซ้ำ ผมเป็นนักพัฒนาและใช้แค่ Firefox กับ uBlock Origin มาเกือบ 10 ปีแล้ว
      ภรรยาผมก็ใช้ Firefox เป็นเบราว์เซอร์หลักหลังจากผมอธิบายให้ฟังและเธอเข้าใจว่าประสบการณ์อินเทอร์เน็ตมันต่างกันได้มากแค่ไหน
      เพราะงั้นผมไม่อยากให้เล่าเรื่องนี้แบบ “การผูกขาดไม่ดีและ Google ก็ค่อนข้างร้าย ดังนั้นช่วยใช้ผู้เล่นรองที่ด้อยกว่าหน่อย” สำหรับงานทุกอย่างที่ผมโยนให้ Firefox มันเป็นประสบการณ์ระดับชั้นหนึ่ง และบนมือถือยิ่งมากกว่านั้นประมาณสามเท่า เป็นประสบการณ์เบราว์เซอร์มือถือที่มีประโยชน์ที่สุดแบบทิ้งห่าง
    • เบราว์เซอร์ไม่จำเป็นต้องมีฟีเจอร์ใหม่มานานมากแล้ว เรื่องแบบนั้นควรเป็นหน้าที่ของ ส่วนขยาย

  • ตั๋วที่ลิงก์มามีแค่ไม่กี่อัน ดังนั้นถ้าได้ดูรายการจริงทั้ง 271 รายการอาจเปลี่ยนมุมมองก็ได้ แต่เท่าที่ผมดูมา ทั้งหมดเป็น บั๊กร้ายแรงในโค้ด C++
    Firefox เขียนด้วยหลายภาษาและ C++ มีสัดส่วนแค่ราว 25% แต่ปัญหาเหล่านี้ดูเหมือนจะไปแตะ C++ ทั้งนั้น

    • ข้อจำกัดทั่วไปของแนวทางนี้คือ มันดีได้เท่ากับตัวตรวจสอบเท่านั้น ตัวอย่างเช่น ไม่มีอะไรตรวจสอบง่ายไปกว่าเคสทดสอบที่ทำให้ AddressSanitizer จับ use-after-free ได้
      คงต้องดูกันว่าปัญหาที่ละเอียดกว่านี้จะต้องมีตัวตรวจสอบที่เฉพาะทางยิ่งขึ้น หรือ LLM จะคิดเงื่อนไขเสี่ยงอื่น ๆ ที่ใช้ตรวจสอบเองได้ดีขึ้นหรือไม่
    • เป็นไปได้ว่า Mythos จะเก่งในการหาช่องโหว่ C++ มากกว่าภาษาอื่น เพราะโมเดลพวกนี้ก็ถูกสร้างขึ้นบนฐานข้อมูลวิเคราะห์ความปลอดภัยที่มีอยู่เดิม
      ในมุมผม บั๊กหลายตัวในนี้ไม่ได้เป็นปัญหาเฉพาะของ C++ เท่าไร แต่เป็นปัญหาที่บังเอิญไปเกิดในโค้ด C++ มากกว่า ต่อให้เป็น Rust ที่ปลอดภัยที่สุดก็ไม่ได้จับปัญหาอย่าง TOCTOU ได้อย่างน่าอัศจรรย์หรอก
    • เพราะมีการตรวจสอบบั๊กด้วย AddressSanitizer อยู่แล้ว จึงแทบถูกกำหนดโดยโครงสร้างให้พบแต่บั๊ก C++

  • พออ่านเรื่องนี้ควบคู่ไปกับท่าทีของคนฝั่ง Zig ที่ไม่อยากแม้แต่จะพิจารณาบั๊กที่ LLM สร้างขึ้นเป็นรายการให้รีวิว มุมมองของผมต่อการเลือกเทคโนโลยีเข้ามาไว้ใน toolchain ก็เปลี่ยนไป

    • ทั้งสองอย่างก็จริง ขึ้นอยู่กับว่าใช้โมเดลไหนและใครเป็นคนส่งบั๊กมา ความสามารถของโมเดลชั้นนำเปลี่ยนจาก เสียงรบกวน 99% ไปเป็น บั๊กใช้ได้จริง 99% ภายในไม่กี่เดือน
      บางโปรเจ็กต์กำลังถูกถล่มด้วยแบบแรกจนต้องมีมาตรการป้องกันไม่ให้มันกลายเป็นการโจมตีแบบปฏิเสธการให้บริการต่อผู้ดูแลรักษาโดยพฤตินัย

  • ตอนอยู่ที่ PalmSource ผมพยายามขออนุมัติงบสำหรับ เครื่องมือวิเคราะห์โค้ดแบบสถิต อย่าง CoVerity หรือ Fortify แต่สายการบริหารบอกว่า “แพงเกินไป”
    ผมใช้เวลาอีกปีหนึ่งเพื่อลดต้นทุนและเสนอแผนที่จำกัดแค่การสแกน network stack คราวนี้กลับได้คำตอบว่า “มันใช้ BSD เป็นฐาน และ BSD ปลอดภัยโดยเนื้อแท้” ซึ่งทั้งสองอย่างไม่จริง
    สุดท้ายผมจึงออกจากบริษัทไป Mozilla และพบคอมเมนต์ /* flawfinder ignore */ กระจายอยู่ทั่วโค้ด
    ผมเดาว่า Mythos อาจแค่เพิกเฉยต่อคำสั่ง flawfinder ignore แล้วรายงานช่องโหว่ที่รู้กันอยู่แล้วในโค้ด

    • โค้ดเปิดอยู่แล้ว ถ้าคุณพิสูจน์ได้ว่านั่นจริง มันจะเป็น ข่าวใหญ่จริง ๆ

  • ผมสงสัยว่านี่จะส่งผลอย่างไรกับ เครื่องมือวิเคราะห์แบบสถิต แม้ลักษณะจะแตกต่างกันมาก แต่หลายครั้งก็บรรลุเป้าหมายเดียวกัน
    เครื่องมือวิเคราะห์แบบสถิตอาจช้าและให้ false positive เยอะ ถ้าโมเดลพวกนี้ดีพอและถูกพอ คนจะเลิกสนใจ static analysis กันเกือบหมดไหม

    • LLM เก่งกว่ามากในเรื่อง การใช้เครื่องมือ มากกว่าการมาแทนที่เครื่องมือ โดยทั่วไปการใช้เครื่องมือเดิมมักเร็วกว่ามากเมื่อเทียบกับการพยายามให้ LLM สร้างผลลัพธ์เดียวกันขึ้นมา
      การใช้เครื่องมือเขียนโค้ดแบบ LLM มาคอยจัดการผลลัพธ์จากเครื่องมือ static analysis อย่างต่อเนื่องนั้นได้ผลดีมาก และการเพิ่ม guardrail เพื่อบังคับไม่ให้ปัญหาหลงเหลืออยู่ก็เป็นความคิดที่ดี คล้ายกับการมี CI check ไว้ยืนยันว่าทุกอย่างสะอาดเรียบร้อย
      false positive มากน้อยขึ้นอยู่กับเครื่องมือ ผมมักหลีกเลี่ยงเครื่องมือที่สร้างแต่ noise และเครื่องมือพวกนี้ก็มักให้ปิดกฎที่มี noise สูงได้ หรือจะให้ LLM แก้ทุกปัญหาไปเลยก็ได้ ถ้าค่าแก้ถูกกว่าค่าเถียงกับกฎ ก็แค่แก้ไป สมัยก่อนมันแพงมากเพราะมนุษย์ต้องทำเอง แต่ตอนนี้ไม่ใช่แล้ว
      ผมเพิ่งใช้วิธีนี้กับการอัปเดตโค้ดเบส Ansible ที่ไม่ได้แตะมาหลายปี มีปัญหา ansible-lint อยู่หลายร้อยรายการ ส่วนใหญ่เป็นคำเตือน deprecation กับคำเตือนที่ไม่ร้ายแรง แต่ผ่านไป 10 นาทีก็เหลือ 0 อัน แม้จะไม่ใช่ปัญหาร้ายแรงมากแต่ก็เป็นหนี้เทคนิคชนิดหนึ่ง ถ้าต้องมานั่งแก้คำเตือนหลายร้อยอันด้วยมือ ผมคงไม่ทำ แต่ถ้าแค่โบกไม้กายสิทธิ์ครั้งเดียวแล้วมันหายหมด ก็ไม่มีเหตุผลจะไม่ทำ ตอนนี้ผมปรับ guardrail ให้รัน ansible-lint ตลอดและแก้ปัญหาให้เลย โดยใช้เวลาเพิ่มแค่ไม่กี่วินาที
    • ความเป็นไปได้ที่น่าสนใจคือให้ LLM ช่วยเสริมให้เครื่องมือ static analysis หา รูปแบบบั๊ก ที่ LLM ค้นพบได้ตั้งแต่แรก [0]
      แทบไม่ต้องสงสัยเลยว่าเครื่องมือ static analysis เร็วกว่าและถูกกว่า จึงขยายไปสู่โค้ดเบสขนาดใหญ่มากได้ดีกว่า และอาจทำให้วิธีของ LLM กลายเป็นเรื่องทั่วไปได้ด้วย
      [0] https://lwn.net/Articles/1068968/
    • เครื่องมือ static analysis ก็อาจเร็วกว่าได้มากและส่วนใหญ่เป็นแบบกำหนดผลได้แน่นอน ดังนั้นเมื่อใส่ใน CI ก็จะจับบั๊กหรือบั๊กที่อาจเกิดได้ก่อนที่มันจะเข้าโค้ดเบส
      ผมดูแลเครื่องมือ static analysis ที่ใช้ใน Firefox CI ถ้าจะใส่แพตช์เข้า tree ของเรา คุณต้องแก้ทุกอย่างทั้ง false positive และ true positive หรือทำเครื่องหมายว่าไม่ใช่ปัญหา กล่าวคือเรายอมให้มีผลลัพธ์ค้างอยู่เป็น 0 ซึ่งเป็นเกณฑ์ที่ค่อนข้างเข้มงวด
      นี่เป็นการแลกเปลี่ยนที่ตั้งใจทำ ถ้าจะให้คนไม่เมินมัน ไม่คอมเมนต์ปิดทับมันหมด หรือไม่เลิกรันมันไปเลย ก็ต้องทำให้อัตราส่วนสัญญาณต่อเสียงรบกวนสูงพอด้วยการลดความเข้มของการวิเคราะห์และยอมรับ false negative บางส่วน เครื่องมือ static analysis เกือบทั้งหมดต้องหาสมดุลแบบนี้
      ในทางกลับกัน AI ที่ใช้กันทั่วไปมีพื้นที่ให้มากกว่า แทบเป็นเรื่องพื้นฐานเลยที่ต้องยอมให้มันหลอน false positive ได้ และนั่นก็เป็นส่วนหนึ่งของพลังของมันด้วย จึงจำเป็นต้องมีการตรวจสอบและยืนยันหลายชั้นครอบอยู่ มันอาจช้า และคุณไม่สามารถพูดได้ว่า “มันจับข้อผิดพลาดรูปแบบนี้ได้ 100%” แต่ถึงอย่างนั้นมันก็จับอะไรได้มหาศาล
      มีข้อมูลตัวอย่างหนึ่งของผม การวิเคราะห์ของผมประเมินผิดว่ามีโอกาสน้อยที่จะเกิดบั๊กจริง และยังดูยุ่งยากเกินไปที่จะลงมือทำ จึงไม่ได้รองรับกรณีหนึ่งไว้ ผมไม่แน่ใจว่าเป็น Opus หรือ Mythos แต่เริ่มมีการรายงานช่องโหว่ที่มาจากกรณีนั้น และผมก็ต้องรีบขยายการวิเคราะห์เพื่ออุดช่องว่าง การลงมือทำใช้เวลาค่อนข้างนาน และตอนสแกน source tree ทั้งหมด Claude ก็ได้พบปัญหาสำคัญที่รายงานไว้ทั้งหมดแล้ว เครื่องมือ static analysis เจอเพิ่มอีกสองสามจุด แต่พูดตรง ๆ ผมก็ยังไม่รู้ว่ามีจุดไหนที่ถูกกระตุ้นได้จริงหรือไม่
      ถึงอย่างนั้นผมก็ยังคิดว่า static analysis มีคุณค่าอยู่ รูปแบบปัญหาบางส่วนอาจเข้าถึงได้ผ่านเส้นทางที่ยากเกินกว่าที่ AI จะประกอบขึ้นได้ในตอนนี้ หรืออาจกลายเป็นปัญหาจริงเมื่อโค้ดอื่นเปลี่ยนไป สำหรับทั้งสองกรณี การแก้ให้หมดตอนนี้ก็ดูมีคุณค่า และยังมีเหตุผลรองลงมาคือไม่ทำให้ AI เสียเวลาไปกับการพยายามโจมตีสิ่งเหล่านั้น ขณะเดียวกันก็เป็นความจริงชัดเจนว่าดุลความคุ้มค่าต่อค่าใช้จ่ายได้เปลี่ยนไปแล้ว
      ทั้งสองอย่างอาจทำงานร่วมกันได้ ผมสามารถผ่อนเกณฑ์ของตัวเอง ให้เครื่องมือวิเคราะห์เขียนรายงานเตือนเพิ่มเติมสำหรับปัญหาที่น่าสงสัย พร้อมระบุชัดว่าคาดว่าจะมี false positive แล้วป้อนรายการนั้นเข้า AI ให้ช่วยตรวจสอบได้ โดยพื้นฐานคือ ป้อนกองสลอปให้เครื่องสร้างสลอป เพื่อให้มันคัดกรองเอาเพชรเม็ดงามออกมาแบบไม่เป็นเชิงกำหนด
      เป็นเรื่องที่น่าคิดต่อ
    • harness พวกนี้น่าจะ ใช้เครื่องมือ static analysis อยู่แล้ว และต่อไปก็น่าจะยังใช้ต่อ

  • ใน Mission Impossible ภาคล่าสุด การจะกู้โลกได้ต้องไปเอาซอฟต์แวร์ต้นฉบับของ AGI เหนือมนุษย์ที่หลบหนีอยู่จากเรือดำน้ำรัสเซียที่จม
    Luther ได้ซอร์สโค้ดต้นฉบับแล้วก็เขียน “poison pill” ที่จบเกม AI ได้ในทีเดียว ผมเคยสงสัยว่าโค้ดเวทมนตร์แบบนั้นเขียนขึ้นมาได้อย่างไร ตอนนี้รู้แล้ว Luthor ก็แค่โยนซอร์สโค้ดให้ Mythos ผ่านพรอมป์ต์แล้วขอ exploit ร้ายแรงที่แก้ไม่ได้ เท่านั้นเอง

  • ผมสงสัยว่าคนอื่นมองอย่างไรว่าอีก 5 ปีข้างหน้า LLM จะทำให้ซอฟต์แวร์ปลอดภัยขึ้นหรือน้อยลง

    • มันคงกำจัดปัญหาบางประเภทได้ และนั่นน่าจะเป็นเรื่องดี อีกทั้งสิ่งที่ยังไม่ปลอดภัยก็อาจย้ายไปภาษาอื่นได้ด้วย
      ก่อนยุค LLM ก็มีแนวโน้มย้ายด้วยมือไป Rust อยู่แล้ว ตอนนี้ LLM จะทำให้งานนั้นง่ายและเร็วขึ้น มูลค่าในระยะยาวจะมาจากการช่วยสะสางหนี้เทคนิคกองมหึมาของโค้ดเบส C/C++ เดิม โค้ดพวกนี้เป็นต้นเหตุของ memory exploit, buffer overflow และปัญหาอื่น ๆ ในสัดส่วนท่วมท้น และแม้จะระวังกันมาหลายสิบปีก็ยังพบต่อเนื่องในโค้ดเบสสำคัญ
      สิ่งที่ Mozilla พบนี้ตั้งอยู่บนความพยายามของวิศวกรที่มีความสามารถมากซึ่งพยายามทำสิ่งที่ถูกต้องมาตลอด 25 ปี และใช้ทุกเครื่องมือที่มีเพื่อป้องกันไม่ให้ปัญหาแบบนี้เกิดขึ้น ผมเคารพทีมนี้มาก รวมถึงสิ่งที่พวกเขาช่วยพัฒนาในช่วงหลายปีที่ผ่านมา ทั้งด้านเครื่องมือ การทดสอบ และแนวปฏิบัติการตรวจสอบ ปัญหาไม่ได้อยู่ที่ความพยายามหรือความสามารถของพวกเขา
      การรับระบบเดิมที่มีการทดสอบดี เอกสารดี และสเปกชัดเจน แล้วสร้าง implementation ทดแทนแบบ drop-in ตอนนี้กลายเป็นงานที่พอจะทบทวนได้แล้ว เมื่อไม่กี่ปีก่อนสิ่งนี้จะพ่วงมาด้วยต้นทุนและความเสี่ยงระดับโครงการใหญ่ แต่ตอนนี้มันเป็นอะไรที่เริ่มลองได้ในบ่ายวันศุกร์ อย่างแย่สุดก็ล้มเหลว อย่างดีที่สุดก็ได้ implementation ที่ดีกว่ามาก
      มันยังอยู่ในช่วงเริ่มต้น และโค้ดที่ LLM สร้างก็ยังมีปัญหาด้านคุณภาพมากมาย แต่โอกาสสำเร็จและอัตราความล้มเหลวน่าจะดีขึ้นเรื่อย ๆ ตามเวลา
    • ทั้งสองอย่าง ผู้มีทักษะจะใช้มันหาปัญหา ส่วนผู้ไม่มีทักษะจะใช้มันสร้าง โค้ดสลอปที่ไม่ปลอดภัย ให้คนมีทักษะต้องมานั่งแก้
    • คล้ายกับที่ร้านอุปกรณ์ซ่อมบ้าน เครื่องมือไฟฟ้า ฮาร์ดแวร์ที่หาซื้อง่าย และคลิปสอนใน YouTube ช่วยให้คนทำเฟอร์นิเจอร์ที่ยอดเยี่ยมและแข็งแรงได้ แต่ก็ทำเฟอร์นิเจอร์ที่หยาบ น่าเกลียด หรือกระทั่งอันตรายได้เช่นกัน
      เมื่อมีเครื่องมือมากขึ้นในมือผู้คนมากขึ้น ก็จะมีของถูกสร้างมากขึ้นและหลากหลายขึ้น
    • ซอฟต์แวร์จะปลอดภัยขึ้น แต่คงเป็นในลักษณะเดียวกับที่ประชากรโดยรวมสุขภาพดีขึ้นหลังโรคระบาด
    • ถ้าใช้อย่างเหมาะสม มันก็จะปลอดภัยขึ้น
      เพียงแต่นั่นก็หมายความว่าสำหรับโปรเจ็กต์ที่ไม่ใช้เครื่องมือเหล่านี้ ฝั่ง blackhat ก็จะมีโอกาสใช้ประโยชน์ได้ง่ายขึ้นด้วย
 
GN⁺ 2026-05-08
ความคิดเห็นจาก Lobste.rs

  • อยากให้เผยแพร่ พรอมป์ต์และฟีเจอร์อื่น ๆ ที่ใช้ในงานนี้ด้วย
    ถ้าใส่พรอมป์ต์ไว้ในรายงานบั๊กหรือรายละเอียดการแก้ไขเพื่อให้ทำซ้ำได้ก็น่าจะดี
    ในเมื่อมีการพูดถึงโมเดลที่ไม่ใช่ Mythos ด้วย บางส่วนของงานนี้ก็ดูเหมือนจะมีประโยชน์กับคนอื่นได้ทันที

    • สำหรับโปรเจ็กต์ส่วนใหญ่ อุปสรรคในการเริ่มต้นต่ำมากจริง ๆ
      โดยพื้นฐานแล้วก็แค่บอกว่า “ช่วยตรวจโปรเจ็กต์นี้จากมุมมองของปัญหาด้านความปลอดภัย โดยเริ่มจาก (ไฟล์) และไล่เส้นทางที่เป็นไปได้ทั้งหมดให้หน่อย” แล้วค่อยตามด้วย “ช่วยตรวจสอบรายงานนี้และสร้าง การพิสูจน์แนวคิด สำหรับแต่ละรายการให้หน่อย”
      ตอนนี้ถ้าใช้ Opus การจะหาอะไรไม่เจอด้วยวิธีนี้กลับยากกว่า
    • คิดหรือว่าพรอมป์ต์จะมากไปกว่า “ช่วยหา ช่องโหว่ด้านความปลอดภัย ในโค้ดเบสนี้ให้หน่อย”?

  • จะพูดอย่างไรก็เถอะ นี่น่าประทับใจจริง ๆ
    พบ ปัญหาด้านความปลอดภัย 271 รายการ ด้วย Mythos และรวมทั้งหมดพบ 423 รายการ
    ในจำนวนนั้น 180 รายการมีความรุนแรงสูง และบางปัญหาด้านความปลอดภัยมีอายุถึง 20 ปี

    • ยังไม่ชัดเจนทั้งหมดว่าการเปรียบเทียบ Opus 4.6 / Mythos ยุติธรรมแค่ไหน
      มันชวนให้ตีความเหมือนว่า Mythos พบ “บั๊ก 271 รายการ” ในโค้ดที่ก่อนหน้านี้สแกนแบบเดียวกันด้วย 4.6 แต่บทความไม่ได้บอกแบบนั้นอย่างตรงไปตรงมา
      เลยสงสัยว่าในชุดทดสอบงานวิจัยมีการเปลี่ยนแปลงอย่างอื่นไปพร้อมกันด้วยหรือเปล่า

  • ส่วนที่บอกว่า “หนึ่งในหลายปัญหา sec-high ที่เราแก้คือเรื่องที่เกี่ยวกับ XSLT” ดูเหมือนจะถูกใส่มาเพราะ ประเด็นถกเถียงเรื่องการถอด XSLT ออก

  • สิ่งที่อยากรู้ที่สุดตรงนี้คือมีการรายงาน ผลบวกลวง ไปมากแค่ไหนด้วย
    สงสัยว่าโมเดลรายงานช่องโหว่ที่เป็นไปได้มากกว่าราวสองเท่า และที่ยกมาในที่นี้คือเฉพาะรายการที่ยืนยันแล้วหรือไม่
    ก็ไม่รู้เหมือนกันว่าโมเดลถึงขั้นทำการทดสอบซ้ำก่อนรายงานหรือเปล่า
    จาก issue ที่เปิดเผยต่อสาธารณะ ดูเหมือนจะมีคอมเมนต์ที่พยายามทดสอบซ้ำอยู่ แต่ก็อาจเป็นบอตที่มีอยู่เดิมทำก็ได้
    ไม่ค่อยรู้ว่าเดิมที Firefox จัดการเรื่องแบบนี้อย่างไร หรือทุกวันนี้ทำร่วมกับ AI อย่างไรบ้าง ถ้ามีคำอธิบายละเอียดกว่านี้ก็น่าจะน่าสนใจมาก