ช่องโหว่ NetAuthAgent บน macOS ที่อาจทำให้รหัสผ่านรั่วไหลได้

• Apple แพตช์ CVE-2024-54471 ใน macOS Sequoia 15.1, Sonoma 14.7.1, Ventura 13.7.1 ที่เผยแพร่เมื่อวันที่ 28 ตุลาคม 2024 โดยในสภาพแวดล้อมก่อนอัปเดต ข้อมูลรับรองที่บันทึกไว้อาจถูกเปิดเผยผ่าน NetAuthAgent ได้
• แก่นของปัญหาคือ MIG server ของ NetAuthAgent เปิด routine สำหรับค้นหา สร้าง และเขียนทับข้อมูลรับรองของไฟล์เซิร์ฟเวอร์บางส่วนไว้ โดยไม่ตรวจสอบผู้ส่งข้อความ
• ผู้โจมตีสามารถส่งข้อความไปยัง Mach service com.apple.netauth.user.gui เพื่อให้ค้นหารายการ internet password ใน Keychain แทน และรับ ชื่อผู้ใช้กับรหัสผ่าน ได้
• ผลกระทบไม่ได้จำกัดอยู่แค่ข้อมูลรับรองของ FTP, Samba, WebDAV และพรินต์เซิร์ฟเวอร์ที่บันทึกผ่าน “Connect to Server” ของ Finder เท่านั้น แต่ยังอาจต่อยอดผ่านเชนอื่นไปถึงการเปิดเผย ข้อมูลบัญชี iCloud และ API token ได้ด้วย
• หลังแพตช์ NetAuthAgent จะตรวจสอบ entitlement ของ process ผู้ส่งด้วย audit token ของ Mach message และจะไม่ตอบกลับหากไม่มี com.apple.private.netauth.useragent.allow=true

---

ขอบเขตแพตช์ CVE-2024-54471

• CVE-2024-54471 เป็นช่องโหว่ของ macOS ที่ได้รับการแก้ไขในอัปเดตความปลอดภัยของ Apple
• เวอร์ชันที่มีแพตช์ทั้งหมดเปิดตัวเมื่อวันที่ 28 ตุลาคม 2024
  • macOS Sequoia 15.1
  • macOS Sonoma 14.7.1
  • macOS Ventura 13.7.1
• อุปกรณ์ macOS ที่ยังไม่ได้อัปเดตเป็นเวอร์ชันดังกล่าวควรอัปเดตทันที

โครงสร้าง IPC ของ macOS และ Mach

• เคอร์เนลของ macOS และ Apple OS ส่วนใหญ่คือ XNU ซึ่งเป็นไฮบริดเคอร์เนลที่รวมองค์ประกอบตระกูล BSD และตัวแปรของ Mach kernel ที่ถูกปรับแก้อย่างมากไว้ด้วยกัน
• Mach ใน macOS สมัยใหม่ยังคงอิง abstraction 4 อย่าง
  • task: สภาพแวดล้อมการรันที่ thread ทำงานอยู่ และเป็นหน่วยพื้นฐานของการจัดสรรทรัพยากร
  • thread: หน่วยพื้นฐานของการใช้ CPU
  • port: ช่องทางสื่อสารที่เป็น message queue ซึ่งเคอร์เนลปกป้องไว้
  • message: ชุดของ data object แบบมีชนิดที่ใช้สื่อสารระหว่าง thread
• port ของ Mach ไม่ใช่ queue ที่เปิดให้ user space เข้าถึงโดยตรง แต่ถูกจัดการในรูปของ port right ภายใน namespace ของชื่อ port ของแต่ละ task
• สิทธิ์หลักมี 2 แบบ
  • send right: หลาย task สามารถมีสิทธิ์นี้สำหรับ port เดียวกันได้
  • receive right: มีได้เฉพาะ task เดียวเท่านั้น
• โครงสร้างนี้สร้าง โมเดล client-server ที่ server task หนึ่งรับข้อความจาก client task หลายตัว
• bootstrap server ของ macOS จะได้รับ port ที่ทุก task มี send right และทำให้ client สามารถร้องขอ send right ของ Mach service ที่ลงทะเบียนด้วยชื่อแบบ string ได้

ช่องว่างด้านการยืนยันตัวตนที่เกิดใน MIG server

• MIG เป็นเครื่องมือที่ห่อการรับส่ง Mach message ให้เป็น interface แบบฟังก์ชัน
• MIG ประกอบด้วย pseudo-C IDL และ compiler โดยจะสร้างไฟล์ต่อไปนี้จากไฟล์ IDL
  • C source สำหรับ client
  • C source สำหรับ server
  • C header ที่ใช้ทั้งสองฝั่ง
• ฟังก์ชันแต่ละตัวเรียกว่า routine และชุดของ routine เรียกว่า subsystem โดยหมายเลข subsystem และดัชนี routine จะสะท้อนอยู่ใน message ID
• ในการสื่อสารฝั่ง user space ของ macOS โดยทั่วไป MIG ถูก XPC API แทนที่ไปแล้ว แต่ XPC เองก็สร้างอยู่บน Mach message เช่นกัน
• ตัว MIG server เองไม่มีกลไกบังคับยืนยันตัวตน ดังนั้นหาก server ไม่ตรวจสอบผู้ส่ง task ใดๆ ที่มี send right ก็สามารถเรียก remote routine ได้
• สำหรับการสำรวจ MIG server ipsw CLI ของ blacktop มีประโยชน์ โดยใช้วิธีค้นหา binary ที่ import symbol NDR_record
  • วิธีนี้อาจพบทั้ง MIG server และ MIG client ด้วย
  • โค้ดฝั่ง server และ client สามารถแยกแยะได้ค่อนข้างง่ายใน disassembler หรือ decompiler

ข้อมูลรับรองที่ NetAuthAgent จัดการ

• NetAuthAgent เป็น user agent บน macOS ที่จัดการข้อมูลรับรองของไฟล์เซิร์ฟเวอร์ เช่น FTP, Samba และ WebDAV
• กล่องโต้ตอบยืนยันตัวตนที่ปรากฏเมื่อเชื่อมต่อไฟล์เซิร์ฟเวอร์ผ่าน “Go → Connect To Server” ของ Finder มาจาก NetAuthAgent หรือ process ที่เกี่ยวข้อง
• หากผู้ใช้เลือก checkbox สำหรับบันทึกรหัสผ่าน ข้อมูลรับรองจะถูกเก็บไว้ใน Keychain ของ macOS
• NetAuthAgent ไม่ได้บันทึกรหัสผ่านโดยตรง แต่ใช้ Keychain เสมือนที่เก็บความลับส่วนกลาง
• รายการใน Keychain มี access control list ของตัวเอง เพื่อโดยทั่วไปจะกันไม่ให้แอปพลิเคชันเข้าถึงความลับที่ไม่ควรเข้าถึง
• อย่างไรก็ตาม หาก process บางตัวเปิดกลไกให้ทำการค้นหา Keychain แทน process อื่นได้ โมเดลความปลอดภัยทั้งหมดอาจอ่อนแอลง

MIG service ของ NetAuthAgent ที่มีช่องโหว่

• NetAuthAgent เปิดเผย MIG server ที่ค้นหาได้จาก bootstrap server
• ชื่อ service คือ com.apple.netauth.user.gui
• server นี้ให้ routine สำหรับอ่าน สร้าง และในบางกรณีเขียนทับข้อมูลรับรองของไฟล์เซิร์ฟเวอร์
• ก่อนแพตช์ routine เหล่านี้ไม่ได้ตรวจสอบผู้ส่งข้อความ
• Routine 19 หรือ message ID 40219 สามารถ proxy การค้นหารายการ class internet password ใน Keychain ได้
• routine นี้รับ dictionary ของ option ที่ serialize แล้วเป็น out-of-line data descriptor และคืนชื่อผู้ใช้กับรหัสผ่านเป็น out-of-line data descriptor สองรายการ

ลำดับการโจมตีและองค์ประกอบของ PoC

• PoC ใช้ Kass ซึ่งเป็นเครื่องมือวิจัยความปลอดภัยที่เขียนด้วย Swift เพื่อจัดการ Mach message และ MIG client
• NetAuthAgent client ถูกกำหนดด้วยค่าต่อไปนี้
  • ชื่อ service: com.apple.netauth.user.gui
  • routine ID อิง subsystem: 40200
• option สำหรับค้นหาถูก serialize ในรูปแบบ Property List และอาจมี field เช่น Scheme, Host, AlternatePort, Path
• SecItemCopyMatching ซึ่งเป็น macOS Keychain API สามารถใช้เพื่อรับ metadata ของรายการ Keychain ได้ แม้โดย process ที่ไม่มีสิทธิ์ หากไม่ได้ขอค่าความลับ
• access control list ก็เข้าถึงได้ในฐานะ metadata เช่นกัน จึงตรวจสอบได้ว่ารายการ trusted application ของ item มี /System/Library/CoreServices/NetAuthAgent.app อยู่หรือไม่
• โค้ดโจมตีสามารถไล่ดูรายการ internet password ที่ NetAuthAgent เข้าถึงได้ และดึงข้อมูลต่อไปนี้ออกมา
  • ชื่อที่แสดง
  • โปรโตคอล
  • โฮสต์
  • พอร์ต
  • พาธ
  • ชื่อผู้ใช้
  • รหัสผ่าน

ผลกระทบจากการรั่วไหลของข้อมูลรับรองไฟล์เซิร์ฟเวอร์

• ก่อนแพตช์ process อันตรายที่ได้ send right ไปยัง NetAuthAgent สามารถรั่วไหล ข้อมูลรับรองไฟล์เซิร์ฟเวอร์ทั้งหมด ได้
• ในสภาพแวดล้อมองค์กร ข้อมูลรับรองดังกล่าวอาจเป็น ข้อมูลรับรอง SSO ทำให้ผู้โจมตีอาจเข้าถึงทรัพยากรหลายรายการในระบบของบริษัทได้
• ไม่ทราบว่าฟีเจอร์ Connect to Server ของ Finder ถูกใช้งานมากเพียงใด แต่เอกสารช่วยเหลือของมหาวิทยาลัยและสถาบันการศึกษาหลายแห่งได้แนะนำให้นักศึกษาและบุคลากรใช้ฟีเจอร์นี้ และบางแห่งแนะนำให้เลือก checkbox สำหรับบันทึกใน Keychain
• ยังพบคู่มือการเชื่อมต่อพรินเตอร์ของผู้ให้บริการพรินต์เซิร์ฟเวอร์ด้วย และ NetAuthAgent ก็จัดการข้อมูลรับรองของพรินต์เซิร์ฟเวอร์เช่นกัน
• มีเอกสารอย่างน้อยหนึ่งฉบับแนะนำไม่ให้เลือก checkbox บันทึก โดยให้เหตุผลว่าเมื่ออัปเดตรหัสผ่านที่บันทึกไว้ แอป Keychain Access ใช้งานยากสำหรับผู้ใช้ทั่วไป
• หากบนอุปกรณ์ที่มีการจัดการ มีการใช้ข้อมูลรับรองเดียวกันเป็นข้อมูลรับรอง superuser ด้วย ก็อาจนำไปสู่การยกระดับสิทธิ์ได้ แต่ยังไม่ได้รับการยืนยันเพราะไม่มีการทดสอบกับอุปกรณ์ที่มีการจัดการ
• สำหรับผู้ใช้ส่วนบุคคลที่เชื่อมต่อ NAS ผ่าน Finder และบันทึกข้อมูลรับรองไว้ ข้อมูลรับรอง NAS ก็อาจถูกเปิดเผยแก่ผู้โจมตีได้เช่นกัน
• หากใช้ข้อมูลรับรองเดียวกันซ้ำกับบัญชีอินเทอร์เน็ตอื่น บัญชีนั้นก็อาจถูกบุกรุกได้
• FTP, Samba และ WebDAV มี interface ที่นิยามไว้ชัดเจน จึงง่ายต่อการทำ automation เพื่อสำรวจและนำไฟล์ออกจากเซิร์ฟเวอร์หลังข้อมูลรับรองรั่วไหล

การนำ Keychain ไปใช้โจมตีเพิ่มเติม

• เนื่องจาก NetAuthAgent เปิดเผย routine สำหรับ สร้าง รายการ Keychain ด้วย process อันตรายจึงสามารถใส่ข้อมูลใดๆ ลงใน field password เพื่อซ่อนไว้ได้
• วิธีนี้สามารถหลีกเลี่ยงการเขียนลงดิสก์โดยตรง จึงอาจเป็นวิธีซ่อนข้อมูลเพื่อหลบเลี่ยงซอฟต์แวร์ความปลอดภัยได้
• ยังไม่เป็นที่ทราบว่ามีซอฟต์แวร์ความปลอดภัยใดตรวจสอบรายการต้องสงสัยใน Keychain อย่างชัดเจนหรือไม่
• process อันตรายยังสามารถบันทึกข้อมูลรับรองที่ถูกต้องตามกฎหมายลงใน Keychain ได้ด้วย
• พฤติกรรมนี้เมื่อใช้ลำพังอาจมีผลจำกัด แต่มีความเป็นไปได้ว่าจะถูกใช้ใน attack แบบผสม โดยบันทึกข้อมูลรับรองของไฟล์เซิร์ฟเวอร์ที่ผู้โจมตีควบคุม แล้วหลอกผู้ใช้ด้วย social engineering

เชน exploit ที่ต่อไปถึง iCloud API token

• ผู้ใช้ที่ไม่ได้ใช้ Connect to Server ก็ไม่ได้ปลอดจากผลกระทบของช่องโหว่นี้
• อุปกรณ์ macOS ส่วนใหญ่มีรายการ Keychain ที่มี ACL กว้างพอให้ NetAuthAgent เข้าถึงได้
• รายการ Keychain นี้มี decryption key สำหรับถอดรหัสไฟล์บางไฟล์บนดิสก์
• ไฟล์ดังกล่าวมี ข้อมูลบัญชี iCloud และ API token ของผู้ใช้
• ผู้โจมตีสามารถใช้รายการ Keychain และไฟล์ในตำแหน่งที่ทราบ เพื่อรับข้อมูลต่อไปนี้
  • ชื่อและนามสกุล
  • ที่อยู่อีเมล
  • อีเมล alias
  • ฟีเจอร์และ endpoint ที่เปิดใช้งานอยู่
  • API token อายุยาวหลายรายการ

สิ่งที่ทำได้ด้วย iCloud token

• งานวิจัยก่อนหน้าของ Wojciech Reguła แสดงให้เห็นว่า API token เดียวกันสามารถถูกพบด้วยวิธีอื่นและใช้รั่วไหลข้อมูลต่อไปนี้ได้
  • Contacts
  • Calendars
  • Reminders
  • ตำแหน่งของผู้ใช้ผ่าน Find My
• มีการทำซ้ำผลลัพธ์เหล่านั้นได้ ยกเว้น Reminders
• Reminders ของบัญชีใหม่และบัญชีที่ถูก migrate ถูก Apple ย้ายไปยัง CloudKit ที่ปลอดภัยกว่า ทำให้เข้าถึงได้เฉพาะในรูปแบบที่เข้ารหัสแล้ว
• สิ่งที่ทำเพิ่มเติมได้มีดังนี้
  • รั่วไหลรูปภาพผู้ติดต่อ
  • ค้นหา CloudKit ได้ แต่ถอดรหัสไม่ได้
  • รั่วไหลข้อมูล iCloud key-value store
  • รั่วไหล metadata ของ iCloud backup รวมถึงหมายเลขซีเรียลของอุปกรณ์
  • รั่วไหลตำแหน่งของอุปกรณ์อื่นของผู้ใช้ผ่าน Find My
  • รั่วไหลตำแหน่งของเพื่อนของผู้ใช้ผ่าน Find My
  • ดำเนินการล็อก ลบ และเล่นเสียงผ่าน Find My
• มีการตรวจสอบการถอดรหัสข้อมูล CloudKit แต่ยังทำไม่สำเร็จ
• ไม่อาจตัดความเป็นไปได้ที่บริษัท forensic เชิงพาณิชย์จะใช้ API token นี้ร่วมกับ PIN ของอุปกรณ์ iOS เมื่อจำเป็น เพื่อถอดรหัสข้อมูล CloudKit หรือข้อมูล CloudKit ใน iCloud backup

วิธีแก้ไขของ Apple

• หลังแพตช์ เมื่อ NetAuthAgent ได้รับข้อความ จะตรวจสอบ entitlement ของผู้ส่งก่อน
• entitlement คือคู่ key-value ที่แนบมากับ binary ตอน code signing
• บน macOS ที่ใช้การตั้งค่าความปลอดภัยมาตรฐาน Apple Mobile File Integrity จะตรวจสอบ restricted entitlement เมื่อ process เริ่มรัน และจะยุติ process หากไม่มี provisioning profile ที่เหมาะสม
• provisioning profile ต้องถูกลงนามโดย Apple ดังนั้นจึงถูกออกแบบมาให้เลี่ยงการตรวจสอบนี้ได้ยาก
• entitlement ที่ NetAuthAgent ต้องการมีดังนี้
  • key: com.apple.private.netauth.useragent.allow
  • value: boolean true
• NetAuthAgent จะไม่ตอบกลับผู้ส่งที่ไม่มี entitlement นี้
• trailer ที่เคอร์เนลแนบเมื่อรับ Mach message มี audit token อยู่ด้วย
• task ฝั่งรับสามารถใช้ audit token เพื่อระบุ task ผู้ส่ง แล้วขอ entitlement dictionary ของ task นั้นจากเคอร์เนลก่อนตรวจสอบค่า

จุดอ่อนในโครงสร้างความปลอดภัย

• แม้ข้อมูลรับรองไฟล์เซิร์ฟเวอร์จะถูกบันทึกให้เข้าถึงได้เฉพาะแอปพลิเคชันบางตัว แต่หากแอปพลิเคชันนั้นยอมรับคำสั่งค้นหาจากแอปพลิเคชันอื่น แอปพลิเคชันนั้นก็จะกลายเป็น จุดอ่อน
• แม้ iCloud API token จะถูกเก็บไว้ในไฟล์เข้ารหัสบนดิสก์ แต่หาก decryption key อยู่ในรายการ Keychain ที่มี ACL กว้าง ACL นั้นก็จะกลายเป็นจุดอ่อน
• macOS มีมาตรการความปลอดภัยที่ทำให้การ inject process ทำได้ยาก และโครงสร้างพื้นฐานด้านความปลอดภัยโดยรวมถือว่าแข็งแรง
• อย่างไรก็ตาม การขาดการตรวจสอบผู้ส่งเพียงอย่างเดียวเช่นในช่องโหว่นี้ อาจนำไปสู่การเปิดเผยทั้งข้อมูลรับรองไฟล์เซิร์ฟเวอร์และ iCloud API token ได้

คำแนะนำสำหรับผู้ใช้

• หากยังทำได้ แนะนำให้เปิดใช้ Advanced Data Protection
• หากไม่ได้ใช้ iCloud ผ่านเว็บเบราว์เซอร์ การปิดใช้งานการเข้าถึงข้อมูล iCloud ทางเว็บ ก็เป็นอีกทางเลือกหนึ่ง
• เว็บไซต์ iCloud อาจใช้ API endpoint คนละชุดกับแอป iCloud ของ Apple
• ช่องโหว่นี้ไม่สามารถเข้าถึง token ได้อีกแล้ว แต่อาจเคยถูกเปิดเผยผ่านช่องโหว่ก่อนหน้า และอาจถูกเปิดเผยผ่านช่องโหว่อื่นในอนาคตได้
• ไม่มีหลักฐานว่า exploit นี้ถูกผู้ไม่หวังดีนำไปใช้หรือค้นพบแล้ว
• ถึงอย่างนั้น หากกังวลเป็นพิเศษว่าข้อมูลรับรองอาจถูกนำไปใช้ในทางที่ผิด ควรเปลี่ยนรหัสผ่าน
• อุปกรณ์ที่ยังไม่ได้อัปเดต macOS หลังเดือนตุลาคม 2024 ควรอัปเดตทันที

[GN⁺]

ความคิดเห็นบน Hacker News

• บทความเขียนได้ดี และทำให้นึกถึง ซีโรเดย์ที่ลองรหัสผ่านว่างสองครั้งแล้วข้ามการล็อกอิน root ได้ ซึ่ง Apple ดูเหมือนพยายามปิดข่าวอยู่บ้าง น่าจะราวปี 2017 หรืออาจเป็น 2018
  ที่ช่องล็อกอิน root ตรงไหนก็ตาม ถ้าใส่ชื่อผู้ใช้ผู้ดูแลระบบแล้วปล่อยรหัสผ่านว่างไว้ ครั้งแรกจะบอกว่ารหัสผ่านผิด แต่พอปิดคำเตือนแล้วกดครั้งที่สอง ก็จะล็อกอินเป็นผู้ใช้นั้นได้
  วันนั้นทำซ้ำได้ 100% และหลังจากแพร่บนโซเชียลมีเดียก็ถูกแพตช์ไม่นาน แต่ก็ยังดูเหมือน oversight ครั้งใหญ่ ดูเหมือนรอบ ๆ กลไกการยืนยันตัวตนของ Mac ยังมีเศษซากเก่า ๆ เหลืออยู่ และการที่มีการพูดถึง ระบบ port ของเคอร์เนล Mach ก็น่าสนใจ

  • เห็นคำว่า รหัสผ่านว่างสองครั้ง แล้วนึกถึงตอนแมวนั่งทับคีย์บอร์ดจนแฮ็ก Sun 3/60 ได้
    พอบัฟเฟอร์ชื่อผู้ใช้ถึง 256 ตัวอักษรสุ่ม XDM ก็แครชแล้วเปิด root shell ขึ้นมาให้ แต่เรื่องนี้เป็นช่วงต้นยุค 90 ที่ทุกคนยังไร้เดียงสาเรื่องความปลอดภัยกว่านี้มาก
  • ดูเหมือนจะเป็นปี 2017 และโพสต์ตอนนั้นชื่อ “macOS High Sierra: Anyone can login as “root” with empty password” - 3001 คะแนน | 1073 ความคิดเห็น - https://news.ycombinator.com/item?id=15800676
  • แค่นั้นยังไม่เท่าไร สมัยก่อนเป็นเวลาหลายปี เราสามารถดึง รหัสผ่าน FileVault ของผู้ใช้คนไหนก็ได้จาก page file ด้วย grep บรรทัดเดียว และใช้ได้ 100%
  • ถ้ารู้จัก Mach แล้วไม่รู้ระบบแกนหลักนี้ได้ก็ออกจะแปลก สำหรับผม ระบบ port นี่แหละคือข้อเท็จจริงตัวแทนที่ใช้อธิบาย Mach
  • เรื่องล็อกอินแบบไม่มีรหัสผ่าน ผมเคยรายงาน CVE-2011-3226 ด้วย และมีอ้างอิงอยู่ที่นี่: https://support.apple.com/en-us/103345

• “ACLs don't”: https://waterken.sourceforge.net/aclsdont/current.pdf

• มีการแก้ไขเล็กน้อยในบทความ: การตรวจ entitlement ไม่ได้อยู่ในชั้น Mach ของเคอร์เนล
  https://github.com/nmggithub/wts/commit/2bdce1c0c76c7adc360e17a6a42ee547462b99d3
  เป็นการเปลี่ยนคำเดียวเพื่อแก้ข้อผิดพลาดเชิงข้อเท็จจริงในส่วนที่อธิบายการทำงานของ XNU

• ส่วนที่ว่า “ถ้าโปรเซสเปิดเผยกลไกที่ทำให้โปรเซสอื่นพร็อกซีคำถาม keychain แทนได้โดยพฤตินัย ก็อาจทำให้ความปลอดภัยของทั้งระบบอ่อนแอลง” ดูเหมือน ปัญหา confused deputy: https://en.wikipedia.org/wiki/Confused_deputy_problem
  ถ้าเป็นการออกแบบแบบ capability-based ก็ควรจะป้องกันปัญหาประเภทนี้ได้อย่างเป็นระบบ

  • Entitlements ก็น่าจะมองได้ว่าเป็น capability ชนิดหนึ่ง ถ้าอย่างนั้นก็พูดถูก และทางแก้จริง ๆ ก็คือทำให้การคุยกับตัว daemon เองต้องมี entitlement

• สงสัยว่าผู้เขียนให้ โค้ด PoC จริง ๆ ไว้ที่ไหน อยากลองทดสอบมาตรการบรรเทาผลกระทบดู แต่เห็นแค่โค้ดตัวอย่างที่ดูเหมือนยังไม่สมบูรณ์
  ความเสี่ยงในทางปฏิบัติอยู่ระดับไหน?

  • โค้ด PoC น่าจะรันได้ แค่ต้องติดตั้ง Kass เป็น dependency ถ้าทำแบบนั้นแล้วยังมีปัญหาอื่น ก็อยากรู้ว่าเป็นปัญหาอะไร
    ในแง่ความเสี่ยง แอปที่ได้ send right ไปยัง NetAuthAgent ซึ่งโดยพื้นฐานแล้วแทบทุกแอปที่ไม่อยู่ใน sandbox สามารถขอข้อมูลประจำตัวที่บันทึกไว้ของไฟล์ไดรฟ์อย่าง FTP, WebDAV, Samba จาก NetAuthAgent แบบเงียบ ๆ ได้ นอกจากนี้ยังอาจนำไปสู่การรั่วไหลของรายชื่อผู้ติดต่อและปฏิทิน iCloud ทั้งหมด รวมถึงข้อมูลอื่น ๆ ที่เกี่ยวข้องกับ iCloud
    sandboxing ทำให้ทำได้ยากขึ้น แต่ไม่ได้ทำให้เป็นไปไม่ได้ ถ้าอัปเดตเป็นเวอร์ชันล่าสุด ความเสี่ยงคือ 0 และแพตช์เข้ามาตั้งแต่เดือนตุลาคมปีที่แล้ว ดังนั้นพูดตรง ๆ ก็ควรอัปเดตกันไปแล้ว ถ้าไม่ได้อัปเดตและไม่คิดจะอัปเดตในอนาคต ความเสี่ยงจะสูงกว่ามาก เว้นแต่จะตรวจสอบทุกโปรเซสที่รันอยู่บนเครื่องอย่างไม่ตกหล่น

• เป็นบทความที่ละเอียดมาก และชอบที่ครอบคลุมไปถึงประวัติของหลายเคอร์เนลด้วย แต่ถ้าเป็นบทความเกี่ยวกับปัญหาความปลอดภัยร้ายแรง ช่วงต้นน่าจะมีคำอธิบายสั้น ๆ มาก ๆ เกี่ยวกับ ขอบเขตผลกระทบ, เงื่อนไขการโจมตี และว่าเป็นบั๊กตรรกะหรือ memory corruption
  ขอแค่สั้นพอให้ตัดสินใจได้ว่าจะอ่านส่วนที่เหลือต่อไหมก็พอ

  • ขอบคุณสำหรับฟีดแบ็ก ตั้งใจเลื่อนจุดสำคัญออกไปนิดเพื่อให้ผู้อ่านอ่านต่อ แต่ก็เข้าใจมุมมองนั้นดี

• เป็นบทความที่น่าสนใจจริง ๆ ไม่รู้มาก่อนว่า เคอร์เนล Mach และ Darwin มีเบื้องหลังการสร้างเยอะขนาดนี้

  • เบื้องหลังมีค่อนข้างเยอะ Mach ย้อนกลับไปได้ถึง Accent ซึ่งเป็นเคอร์เนลของ CMU ที่เก่ากว่านั้นอีก: https://en.wikipedia.org/wiki/Accent_kernel

• ถึงตอนนี้ Mach ให้ความรู้สึกเหมือนเป็นแหล่งผลิตบั๊ก macOS ที่เสถียรไปแล้ว รู้ว่า Apple กำลังล็อกมันอย่างจริงจัง แต่มีเส้นทางที่จะออกจาก Mach อย่างสมบูรณ์ไหม?

  • ในกรณีนี้ ผมมองว่าสาเหตุของบั๊กไม่ใช่ Mach แต่เป็น การขาดการตรวจ entitlement มากกว่า Entitlements พูดตามตรงคือเป็นระบบความปลอดภัยที่ดีมาก แต่เป็นแบบ opt-in
    ถ้า daemon ไม่ตรวจ entitlement ก็ไม่ปลอดภัย ควรโทษวิธีใช้มันมากกว่าจะโทษกลไก messaging
    จริง ๆ แล้วระบบ messaging ที่ถูกล็อกไว้แบบใดก็ตามก็ต้องการมากกว่าการส่งข้อความธรรมดา เช่น การตรวจสอบผู้ส่ง ซึ่งไม่ใช่สิ่งที่จะได้มาฟรี ๆ จากโปรโตคอลสื่อสารระดับต่ำอย่าง Mach เว้นแต่ Apple จะปรับปรุงคอมไพเลอร์ MIG เพื่อเพิ่มการตรวจ entitlement
    Mach ใช้ได้ยอดเยี่ยมเมื่อใช้ร่วมกับการตรวจ entitlement
  • เมื่อไม่นานมานี้มีบทความที่พูดถึงการย้ายส่วนต่าง ๆ ออกจาก Mach มากขึ้นเรื่อย ๆ บางส่วนไปที่ L4 และบางส่วนไปที่ user space
    ในเชิงเทคนิค การมีคอมโพเนนต์ต่างชนิดอยู่ร่วมกันมากขึ้นอาจเพิ่มพื้นผิวโจมตีที่เป็นไปได้ แต่พื้นผิวที่เฉพาะทางมากขึ้นจะทำให้การควบคุมง่ายขึ้น และท้ายที่สุดอาจทำให้ปกป้องพื้นผิวนั้นได้ดีกว่า