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

 (hacks.mozilla.org)
1 คะแนน โดย GN⁺ 1 시간 전 | 1 ความคิดเห็น | แชร์ทาง 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 และทำให้สามารถทุ่มทรัพยากรไปกับการค้นหาและแก้ไขช่องโหว่ได้มากขึ้น

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

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

 
GN⁺ 1 시간 전
ความคิดเห็นจาก Lobste.rs

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

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

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

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

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

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