ช่องโหว่หน่วยความจำเสียหายในเคอร์เนล macOS ที่เปิดเผยสู่สาธารณะครั้งแรกบน Apple M5

 (blog.calif.io)
2 คะแนน โดย GN⁺ 2026-05-15 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • วิศวกรของ Calif ได้สร้างเอ็กซ์พลอยต์หน่วยความจำเสียหายในเคอร์เนล macOS ที่ทำงานบน Apple M5 และส่งรายงานวิจัยช่องโหว่ให้ Apple
  • เชนเอ็กซ์พลอยต์นี้มุ่งเป้าไปที่ฮาร์ดแวร์ M5 แบบ bare-metal ที่เปิดใช้ MIE
  • เป้าหมายคือ macOS 26.4.1 (25E253) และสามารถไต่สิทธิ์จากผู้ใช้ภายในเครื่องที่ไม่มีสิทธิ์ไปถึง root shell ได้ด้วย system call ปกติเท่านั้น
  • การพัฒนานี้ใช้ ช่องโหว่สองรายการ และหลายเทคนิค โดย Calif ระบุว่านี่คือเอ็กซ์พลอยต์เคอร์เนล macOS ตัวแรกที่เปิดเผยต่อสาธารณะบนฮาร์ดแวร์ MIE
  • Mythos Preview ช่วยในการระบุบั๊กและพัฒนาเอ็กซ์พลอยต์ แต่การหลบเลี่ยงมาตรการป้องกันใหม่อย่าง MIE ยังต้องอาศัยผู้เชี่ยวชาญมนุษย์

เอ็กซ์พลอยต์เคอร์เนล macOS ที่ผ่าน MIE ของ M5

  • วิศวกรของ Calif ร่วมกับ Mythos Preview ได้สร้างเอ็กซ์พลอยต์หน่วยความจำเสียหายในเคอร์เนล macOS ที่ทำงานบนชิป Apple M5 และนำส่งรายงานวิจัยช่องโหว่ให้ Apple ด้วยตนเองที่ Apple Park
  • เชนนี้มุ่งเป้าไปที่ฮาร์ดแวร์ M5 แบบ bare-metal ที่เปิดใช้ MIE(Memory Integrity Enforcement)
  • เป้าหมายคือ macOS 26.4.1 (25E253) โดยเป็นเชนการยกระดับสิทธิ์ในเครื่องระดับเคอร์เนลแบบอาศัยข้อมูลล้วน ซึ่งเริ่มจากผู้ใช้ภายในเครื่องที่ไม่มีสิทธิ์ ใช้เพียง system call ทั่วไป และจบลงด้วย root shell
  • การพัฒนานี้ประกอบด้วย ช่องโหว่สองรายการ และหลายเทคนิค และหลังจาก Apple แก้ไขช่องโหว่กับเส้นทางการโจมตีแล้ว จะมีการเผยแพร่รายงานความยาว 55 หน้าและรายละเอียดทางเทคนิคทั้งหมด
  • กำหนดการดำเนินไปอย่างรวดเร็ว
    • Bruce Dang พบบั๊กเมื่อวันที่ 25 เมษายน
    • Dion Blazakis เข้าร่วม Calif เมื่อวันที่ 27 เมษายน
    • Josh Maine สร้างเครื่องมือ และเอ็กซ์พลอยต์ที่ใช้งานได้เสร็จสมบูรณ์ในวันที่ 1 พฤษภาคม

ความหมายของ MIE และ Mythos Preview

  • หน่วยความจำเสียหายยังคงเป็นประเภทช่องโหว่ที่พบบ่อยที่สุด รวมถึงใน iOS และ macOS และหากไม่สามารถป้องกันได้ทั้งหมด ก็จำเป็นต้องมีมาตรการบรรเทาที่เพิ่มต้นทุนของการโจมตี
  • Apple ใส่ฟังก์ชันป้องกันจำนวนมากไว้ในฮาร์ดแวร์โดยคำนึงถึงทั้งประสิทธิภาพและความปลอดภัย และเพิ่มความยากในการหลบเลี่ยงด้วยการควบคุมทั้งสแตกทั้งหมด
  • MIE คือระบบความปลอดภัยของหน่วยความจำที่มีฮาร์ดแวร์ช่วยรองรับ โดยอิงจาก MTE (Memory Tagging Extension) ของ ARM และถูกนำมาใช้เป็นฟีเจอร์ความปลอดภัยหลักของ Apple M5 และ A19
  • ตามงานวิจัยของ Apple, MIE รบกวนเชนเอ็กซ์พลอยต์ที่เปิดเผยต่อสาธารณะทั้งหมดที่โจมตี iOS สมัยใหม่ รวมถึงชุดเอ็กซ์พลอยต์ Coruna และ Darksword ที่รั่วไหลออกมาล่าสุด
  • Calif ได้สำรวจว่า AI สามารถมีส่วนช่วยในการสร้างเอ็กซ์พลอยต์ที่ทำงานได้ในสภาพแวดล้อม MTE อย่างไร และเมื่อ MIE ของ Apple ซึ่งเดิมเน้น iOS ถูกนำมาใช้กับ M5 ใน MacBook รุ่นล่าสุด เส้นทางโจมตีบน macOS จึงเป็นไปได้
  • Mythos Preview ช่วยตลอดทั้งการระบุบั๊กและการพัฒนาเอ็กซ์พลอยต์ และสำหรับปัญหาประเภทที่เคยเรียนรู้มาแล้ว ก็สามารถขยายผลไปยังปัญหาประเภทใกล้เคียงกันได้
  • เหตุผลที่ Mythos หาบั๊กได้รวดเร็วเป็นเพราะบั๊กเหล่านั้นอยู่ในประเภทที่เป็นที่รู้จักอยู่แล้ว ส่วนการหลบเลี่ยงมาตรการบรรเทาขั้นสูงแบบใหม่อย่าง MIE ได้ด้วยตนเองนั้น ยังเป็นงานของผู้เชี่ยวชาญมนุษย์
  • Calif ทดสอบขอบเขตของสิ่งที่เป็นไปได้เมื่อรวมโมเดลระดับแนวหน้ากับผู้เชี่ยวชาญเข้าด้วยกัน และการผสมผสานนี้สามารถทำเอ็กซ์พลอยต์หน่วยความจำเสียหายในเคอร์เนลให้เสร็จภายในหนึ่งสัปดาห์ แม้ต้องเผชิญกับกลไกป้องกันระดับสูงสุด
  • MIE ไม่ใช่อุปกรณ์ที่จะหยุดแฮ็กเกอร์ได้อย่างสมบูรณ์ และหากมีช่องโหว่ที่เหมาะสมก็ยังสามารถหลีกเลี่ยงได้
  • ในซีรีส์ MAD Bugs มีมุมมองว่าระบบ AI กำลังค้นพบช่องโหว่ได้มากขึ้นเรื่อย ๆ และบางส่วนอาจทรงพลังพอจะผ่านมาตรการบรรเทาขั้นสูงอย่าง MIE ได้
  • ในช่วงที่ Apple สร้าง MIE นั้นยังไม่มีสภาพแวดล้อมแบบ Mythos Preview และงานครั้งนี้เป็นผลลัพธ์ระยะแรกที่แสดงให้เห็นถึงแรงกดดันที่การค้นหาบั๊กด้วย AI สร้างขึ้นต่อเทคนิคการบรรเทาขั้นสูง

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

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

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

  • ดูจากเดโมอย่างเดียว บนแพลตฟอร์ม bug bounty ของ Apple มันน่าจะเป็น ช่องโหว่มูลค่า 100,000 ดอลลาร์ แต่ถ้าห่อแพ็กดี ๆ ก็อาจกลายเป็น ช่องโหว่มูลค่า 1.5 ล้านดอลลาร์ ได้
    แค่ทำให้เกิดซ้ำบน macOS รุ่นเบตา จัดให้เป็นการเข้าถึงโดยไม่ได้รับอนุญาต และถ้าเป็นไปได้ก็สาธิตให้เห็นในโหมด Lockdown ด้วย

    • อันนี้ดูเหมือนจะเป็น การยกระดับสิทธิ์ในเครื่อง (LPE) ส่วนที่พูดข้างบนนั้นใกล้เคียงกับการรันโค้ดจากระยะไกลแบบไม่ต้องคลิก (RCE) มากกว่า

  • ดูเหมือนโลกจะยังไม่พร้อมเลยกับ ผลกระทบของ LLM ต่อประเด็นด้านความปลอดภัย
    ถ้าเป็นเรื่องจริงก็ต้องขอแสดงความยินดีกับทีม Calif และแม้รายละเอียดจะเทคนิคมากจนคงเข้าใจไม่หมด แต่ก็กำลังรอรายงาน 55 หน้าอยู่

    • ฉันก็เห็นด้วย แต่สิ่งที่กังวลคือผู้คน
      ได้ยินมาจากหลายที่ว่านักพัฒนากำลังดัน โค้ดที่ LLM สร้างขึ้น เข้าโปรดักชันทั้งที่ตัวเองยังไม่เข้าใจด้วยซ้ำว่ากำลังปล่อยอะไรออกไป
      ยิ่งมีการเปลี่ยนแปลงสะสมมากขึ้น ความเข้าใจต่อโค้ดเบสก็ยิ่งลดลง และพฤติกรรมก็ยิ่งเสี่ยงขึ้น
      ที่แย่กว่านั้นคือพฤติกรรมแบบนี้กำลังถูกผลักดันจากฝ่ายบริหารทั้งทางตรงและทางอ้อม เช่น เป้าความเร็วที่ไม่สมจริง การให้เลื่อนตำแหน่งผ่านโครงการ "การใช้ AI" แบบกำกวม การเลย์ออฟจนทำให้นักพัฒนาที่เหลือต้องรับภาระเกินตัว หรือการให้นักพัฒนาที่ประสบการณ์ยังไม่พอไปนั่งทำบทบาทระดับซีเนียร์
      เหมือนโลกกำลังบ้าคลั่ง และอุตสาหกรรมส่วนใหญ่กำลังจะกลับไปเรียนพื้นฐานด้านความปลอดภัยใหม่อย่างยากลำบาก
    • เหมือนกำลังตั้งสมมติฐานว่าทีม blue team กับวิศวกรไม่ทำอะไรเลยนอกจากนั่งเฉย ๆ

  • ในอีกไม่กี่ปีข้างหน้า LLM จะสร้าง ช่องโหว่แบบ Rube Goldberg ออกมาเป็นจำนวนมาก
    มันเริ่มขึ้นแล้ว และแม้เคสนี้จะไม่ใช่แบบนั้น แต่เรื่องนี้กำลังเกิดขึ้นจริง

    • ในทางทฤษฎี การสร้างระบบที่ปลอดภัยจริง ๆ อาจเป็นสิ่งที่เป็นไปไม่ได้ทางกายภาพตั้งแต่แรก
      เหมือนกับที่ไม่มีเซลล์ใดที่ไม่อ่อนแอต่อไวรัสทุกชนิด
      บางทีที่ผ่านมาพวกเราอาจอยู่รอดได้ด้วย security through obscurity รูปแบบหนึ่ง และความคลุมเครือนั้นอาจหมายถึงแค่ไม่มีใครมีเวลาหรือสมาธิมากพอจะวิเคราะห์โค้ดจริง ๆ
    • สงสัยว่าหมายถึงการฝังช่องโหว่แบบนั้นเข้าไปในเคอร์เนลด้วย vibe coding หรือหมายถึงการค้นพบมัน

  • น่าเสียดายที่รายละเอียดค่อนข้างน้อยไปหน่อย
    อยากรู้มากว่าบั๊กนี้ผ่าน MTE ไปได้อย่างไร

    • Memory Tagging Extension
      Arm เผยแพร่สเปกของ Memory Tagging Extension (MTE) ในปี 2019 ในฐานะเครื่องมือที่ช่วยให้ฮาร์ดแวร์ตรวจหาบั๊ก memory corruption ได้
      MTE เป็นระบบการติดแท็กหน่วยความจำและการตรวจสอบแท็ก โดยจะติดแท็กเป็นค่าลับให้กับการจัดสรรหน่วยความจำทุกครั้ง
      จากนั้นฮาร์ดแวร์จะอนุญาตให้เข้าถึงได้ก็ต่อเมื่อคำขอเข้าถึงหน่วยความจำนั้นมีค่าลับที่ถูกต้องมาด้วย
      ถ้าค่าลับไม่ตรง แอปจะ crash และมีการบันทึกเหตุการณ์ ทำให้นักพัฒนาระบุบั๊ก memory corruption ได้ทันทีที่เกิดขึ้น
      https://support.apple.com/guide/security/operating-system-in...
    • พอไปอ่านเรื่อง data-only attack เพิ่มก็เข้าใจแล้ว
      (https://www.usenix.org/publications/loginonline/data-only-at...)
      ตัวโปรแกรมไม่ได้ถูกเปลี่ยนจริง ๆ และไม่ได้บังคับให้เกิดพฤติกรรมที่ MTE ต้องเข้ามาแทรกแซง จึงไม่ทำให้ MTE ถูกทริกเกอร์
      อีกเรื่องที่สงสัยคือทำไม Apple ไม่ใช้การตรวจสอบ fbounds ที่นี่
      เพราะในจุดอื่น ๆ ก็ใช้ค่อนข้างเข้มข้น
      ถ้าใช้ MTE ร่วมกับการตรวจสอบ fbounds อย่างครอบคลุม ระบบปฏิบัติการก็น่าจะแข็งแกร่งอย่างมาก
    • หน่วยความจำของ GPU, shader และอื่น ๆ ไม่ได้ถูกป้องกันด้วย MTE หรือ PAC
      ในเมื่อบอกว่าเป็น "data-only" คำสั่ง GPU ก็อาจเข้าข่ายนี้ได้
    • ฉันก็มีคำถามเดียวกัน และถ้านี่เป็น data-only attack ก็บางทีอาจเป็นบทเรียนว่า MIE ช่วยลดเส้นทางการโจมตีได้มาก แต่ไม่ได้กำจัด primitive การทำให้ข้อมูลเสียหายที่ยังใช้ประโยชน์ได้ทั้งหมด
    • นี่ไม่ใช่ครั้งแรกที่บั๊กผ่าน MTE ได้
      ปีที่แล้วก็มีเหตุการณ์คล้ายกันบน Google Pixel
      https://github.blog/security/vulnerability-research/bypassin...

  • น่าแปลกที่ Apple ยังไม่ใช้ Swift ซึ่งอ้างว่าเป็นภาษาที่ปลอดภัย ภายในองค์กรอย่างจริงจังเสียที
    ชวนให้คิดว่า Swift 6 ทั้งหมดแทบเป็นการตลาดหรือเปล่า

    • ใช้อยู่แน่นอน
      หนึ่งในเหตุผลที่มี Embedded Swift ก็เพื่อจะนำมาแทนที่ เฟิร์มแวร์ iBoot ซึ่งตอนนี้เขียนด้วยภาษาถิ่นของ C ที่มีแนวคิดคล้าย Fil-C ด้วยสิ่งที่ดีกว่า
      แต่ก็ไม่ได้ต่างจากเคอร์เนล Linux
      ต่อให้อนุญาตให้ใช้ Rust ก็ไม่ได้แปลว่าโลกทั้งใบจะถูกเขียนใหม่หมด และถ้ายังมีสติอยู่ก็คงไม่มีใครพยายามให้ Claude มาเขียนเคอร์เนลใหม่
    • Apple ใช้ Swift อยู่ชัดเจน
      ช่วงหลังเพิ่งเพิ่มเข้าไปใน ตัวแยกวิเคราะห์ CSS ของ Safari และยังทำงานในบางส่วนของ Secure Enclave ในรูปแบบ embedded ด้วย
      เท่าที่รู้ มีการคุยกันมาตั้งแต่สมัย Strangeloop ว่าจะใส่มันลงในเคอร์เนล แต่ไม่แน่ใจว่าไปถึงไหนแล้ว
      แยกจากเรื่องนั้น Apple ก็ผลักดันการตรวจสอบ fbounds ของ clang อย่างจริงจัง ซึ่งช่วยบรรลุบางส่วนเล็กแต่สำคัญของสิ่งที่ภาษา memory-safe มอบให้ได้
      อยากเห็นการนำ Swift หรือภาษาอื่นทางเลือกมาใช้มากขึ้นเช่นกัน และการมีการแข่งขันมากขึ้นในพื้นที่ของภาษาที่ปลอดภัยก็เป็นเรื่องน่ายินดีเสมอ
    • คุณอาจสนใจตัวเลือก Strict Memory Safety
      https://docs.swift.org/compiler/documentation/diagnostics/st...

  • ฉันจงใจซื้อ M5 เพราะ MIE แต่ตอนนี้รู้สึกเหมือนตัวเองโง่นิด ๆ

    • ไม่จำเป็นต้องรู้สึกแบบนั้น
      MTE ยังช่วยกันช่องโหว่ก้อนใหญ่จำนวนมากได้ และทำให้เทคนิคอย่าง ROP กับ JOP ยากมาก หรือแทบเป็นไปไม่ได้เลยในทางปฏิบัติ
    • ควรกังวลเรื่อง มัลแวร์จาก npm/PyPI มากกว่าบั๊ก memory corruption

  • บทความถูกแก้ไขหรือเปล่า? แทบไม่มีคำอธิบายเรื่อง การเข้าเยี่ยมสถานที่จริง เลย

  • ดูเหมือนเป็นการตลาดที่โอ้อวดเกินจริงให้ Mythos อีกชิ้นหนึ่ง
    รายงานของ curl สุขุมกว่านี้มาก
    https://daniel.haxx.se/blog/2026/05/11/mythos-finds-a-curl-v...

    • คนกลุ่มนี้ไม่ได้ทำงานที่ Apple หรือ Anthropic