ป๊อปอัปขอสิทธิ์ของ macOS เชื่อถือได้จริงหรือ?

• CVE-2025-31250 เป็นช่องโหว่ที่ทำให้ป๊อปอัปขอความยินยอมสิทธิ์ของ TCC บน macOS ไม่น่าเชื่อถือ เพราะสามารถทำให้แอปที่แสดงบนหน้าจอกับแอปที่ได้รับสิทธิ์จริงเป็นคนละแอปกันได้
• ปัญหาอยู่ที่การจัดการ TCCAccessRequestIndirect ของ tccd โดย target_path ถูกใช้กับชื่อแอปที่แสดงในป๊อปอัป ส่วน target_identifier ถูกใช้กับตัวระบุแอปที่ได้รับสิทธิ์จริง
• ไม่จำเป็นต้องใช้แอปปลอม, ช็อตคัตบน Dock หรือการล่อให้ผู้ใช้คลิกแบบวิธี bypass เดิม และหากผู้ใช้กด Allow บนป๊อปอัปที่ถูกสวมรอย การโจมตีก็อาจสำเร็จได้
• Apple แก้ไขใน macOS Sequoia 15.5 แต่ Ventura 13.7.6 และ Sonoma 14.7.6 ที่ออกวันเดียวกันไม่ได้รับแพตช์ และยืนยันว่าไม่มีแผนแพตช์ให้เวอร์ชันก่อนหน้า
• ผู้โจมตีสามารถอาศัยจังหวะที่แอปอย่าง FaceTime, Voice Memos หรือ System Settings เปิดขึ้นมาเพื่อพยายาม สวมรอยป๊อปอัปขอสิทธิ์ ทำให้ผู้ใช้อาจเข้าใจผิดว่าได้ให้สิทธิ์กับแอปอื่น

---

กลไกสำคัญของ CVE-2025-31250

• CVE-2025-31250 เป็นช่องโหว่ที่ทำให้แอปที่แสดงในป๊อปอัปสิทธิ์ของ TCC บน macOS ต่างจากแอปที่ได้รับสิทธิ์จริงได้
• ก่อนมีแพตช์ สามารถจัดองค์ประกอบได้ดังนี้
  • Application A ร้องขอให้ macOS แสดงป๊อปอัปขอความยินยอมสิทธิ์
  • ป๊อปอัปดูเหมือนมาจาก Application B
  • ผลการยินยอมของผู้ใช้ถูกนำไปใช้กับ Application C
• ทั้งสามแอปสามารถเป็นคนละตัวกันได้ แม้ในการใช้งานปกติมักมีแนวโน้มจะเป็นแอปเดียวกัน
• แก่นของปัญหาคือไม่มีการตรวจสอบอย่างเพียงพอว่าแอปที่แสดงในป๊อปอัปกับแอปที่ได้รับสิทธิ์จริงต้องตรงกัน

ขอบเขตของแพตช์และข้อมูลแก้ไข

• ต่างจากคำอธิบายแรก แพตช์ถูกใช้เฉพาะกับ macOS Sequoia 15.5 เท่านั้น
• macOS Ventura 13.7.6 และ macOS Sonoma 14.7.6 ที่ปล่อยออกมาในวันเดียวกันไม่ได้รับแพตช์
• เมื่อนำ PoC ไปคอมไพล์และรันบนเครื่องเสมือน Sonoma 14.7.6 พบว่าช่องโหว่ยังทำงานได้อยู่
• Apple Product Security เปลี่ยนสถานะรายงานเป็น “We’ve addressed the issue in all planned releases.” และภายหลังยืนยันว่าไม่มีแผนแพตช์ช่องโหว่นี้สำหรับ Ventura และ Sonoma
• ผลคือ Ventura และ Sonoma ยังคงอยู่ในสถานะที่เสี่ยงต่อช่องโหว่นี้

จุดที่ TCC และ Apple Events มาบรรจบกัน

• TCC เป็นระบบสิทธิ์หลักของระบบปฏิบัติการ Apple และภายในทำงานผ่านดีมอน tccd และ private framework TCC
• นักพัฒนาไม่ได้เรียก private API โดยตรง แต่ public API จะเรียกใช้ความสามารถของ TCC ภายในเมื่อจำเป็น
• tccd รับข้อความผ่าน XPC API ของ Apple
• ก่อนมีแพตช์ แอปที่สามารถส่งข้อความ XPC ไปยัง tccd ได้ สามารถส่งข้อความที่ถูกดัดแปลงเพื่อแยกแอปที่แสดงในป๊อปอัปออกจากแอปที่ได้รับสิทธิ์จริงได้

Apple Events และโมเดลข้อมูลของ TCC

• Apple Events เป็นวิธีสื่อสารระหว่างโปรเซสของ macOS และปัจจุบันใช้หลัก ๆ เพื่อการทำ automation
• Apple Events automation สามารถเขียนสคริปต์ได้ผ่าน Open Scripting Architecture ของ Apple
  • ภาษาหลักคือ AppleScript
  • และยังใช้ JavaScript ได้ด้วย
• ตั้งแต่ macOS Mojave 10.14 เป็นต้นมา แอปที่ต้องการส่ง Apple Events ต้องได้รับความยินยอมจากผู้ใช้ผ่าน TCC
• ผลการยินยอมของ TCC ถูกเก็บไว้ในฐานข้อมูล SQLite Application Support/com.apple.TCC/TCC.db ใต้โฟลเดอร์ home ของผู้ใช้
• แถวข้อมูล TCC ทั่วไปจะมีแอปที่ร้องขอ, service ที่ร้องขอ และผลการยินยอมของผู้ใช้
• Apple Events ต้องจำกัดสิทธิ์ตามแอปรับแต่ละตัว จึงใช้คอลัมน์ indirect object
  • คอลัมน์นี้เก็บตัวระบุของแอปที่จะรับ Apple Events
  • นอกจาก Apple Events แล้ว service FileProviderDomain ก็ใช้คอลัมน์นี้เช่นกัน

โครงสร้างข้อความ XPC ที่มีช่องโหว่

• ปัญหาเกิดจากบั๊กเชิงตรรกะในฟังก์ชัน TCCAccessRequestIndirect
• ฟังก์ชันนี้จัดการคำขอเข้าถึงที่ต้องใช้คอลัมน์ indirect object ของ TCC.db
• หัวใจของ PoC คือการแยกใส่สองฟิลด์เมื่อ target_prompt เป็น 2
  • target_path: ใช้ดึงชื่อแอปที่จะแสดงในป๊อปอัปสิทธิ์แบบ GUI
  • target_identifier: ใช้เป็น bundle ID ของแอปที่จะถูกบันทึกลงฐานข้อมูลและได้รับสิทธิ์จริง
• แม้ TCCAccessRequestIndirect จะเป็นฟังก์ชันสำหรับ indirect object แต่ก็ยังถูกใช้กับหลาย TCC service ที่ไม่ได้ใช้คอลัมน์นั้นได้ โดยใส่ indirect object เป็นสตริงว่าง
• บั๊กนี้ไม่มีอยู่ในฟังก์ชันคำขอเข้าถึงอื่น ๆ

เงื่อนไขและข้อจำกัดของการโจมตี

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

การหลอกด้วยจังหวะเวลาของป๊อปอัป

• หากป๊อปอัปสิทธิ์เด้งขึ้นมาแบบสุ่ม ผู้ใช้อาจสงสัยและกด Don’t Allow
• แอปบน macOS สามารถตรวจสอบรายชื่อแอปที่กำลังรันและแอปที่อยู่หน้าสุดในขณะนั้นได้
  • ตรวจสอบแอปที่กำลังรัน: NSWorkspace runningApplications
  • ตรวจสอบแอปหน้าสุด: NSWorkspace frontmostApplication
• แอปอันตรายสามารถรอจนกว่าแอปเป้าหมายจะถูกเปิดหรือกลายเป็นแอปหน้าสุด แล้วจึงแสดงป๊อปอัปสิทธิ์ที่สวมรอยด้วยชื่อแอปนั้น
• ตัวอย่างเช่น สามารถสวมรอยป๊อปอัปสิทธิ์ Camera ตอนเปิด FaceTime หรือสวมรอยป๊อปอัปสิทธิ์ Microphone ตอนเปิด Voice Memos
• ผู้ใช้อาจเข้าใจผิดว่าป๊อปอัปที่ปรากฏทันทีหลังเปิดหรือสลับไปยังแอป เป็นคำขอสิทธิ์ปกติจากแอปนั้นจริง ๆ

ความเชื่อมโยงกับเส้นทาง bypass TCC แบบเดิม

• ก่อนหน้านี้มีวิธี bypass TCC ได้ เพราะ tccd ใช้ตัวแปรสภาพแวดล้อม HOME เพื่อตัดสินว่าโฟลเดอร์ home ของผู้ใช้อยู่ที่ไหน ทำให้สามารถวางโฟลเดอร์ home ปลอมและ TCC.db ปลอมได้
• ปัญหานี้ถูกแพตช์ในอัปเดตราวกลางเดือนกรกฎาคม 2020 และหลังจากนั้น tccd จะดูโฟลเดอร์ home จาก user information directory ของระบบปฏิบัติการแทน
• หลังจากนั้นก็ยังมีกรณี bypass ที่อาศัยการเปลี่ยนโฟลเดอร์ home ของผู้ใช้อยู่
  • Wojciech Reguła เปิดเผย CVE-2020-27937 ที่อาศัยระบบปลั๊กอินตัวแก้ไข GUI user information directory ของ macOS
  • ทีม Microsoft Threat Intelligence เปิดเผย bypass powerdir ที่ใช้คำสั่ง import/export
• โดยทั่วไปการเปลี่ยนโฟลเดอร์ home ของผู้ใช้ต้องมีสองอย่าง
  • สิทธิ์ root
  • ความยินยอมของผู้ใช้สำหรับ TCC service บางรายการ
• CVE-2025-31250 ไม่ได้ข้ามข้อกำหนดเรื่องสิทธิ์ root แต่สามารถล่อให้ได้ความยินยอม TCC ที่จำเป็นผ่านป๊อปอัปสวมรอย
• หากแอปอันตรายหลอกให้ผู้ใช้ยินยอมได้ และยังยกระดับเป็นสิทธิ์ root ได้ด้วย ก็อาจเปิดทางไปสู่การเปลี่ยน user information directory และวาง TCC.db ปลอมได้
• REG.db ใช้ติดตาม TCC.db ที่มีผลใช้งาน แต่ใน TCC มีฟังก์ชันที่ทำให้แอปเพิ่มรายการลง REG.db ได้ จึงสามารถเพิ่มพาธของ TCC.db ที่วางไว้ได้

ข้อจำกัดของการจัดการสิทธิ์ที่ผู้ใช้มองเห็นได้

• TCC เป็นระบบที่ทำงานอยู่เบื้องหลังแผง Privacy & Security ใน System Settings
• ผลการยินยอมที่เกี่ยวกับ Apple Events จะแสดงในส่วน Automation
• ในแผง Privacy & Security ผู้ใช้สามารถตรวจสอบสิทธิ์ที่เคยอนุญาตไว้ และในหลายกรณีสามารถเพิกถอนสิทธิ์บางรายการได้
• อย่างไรก็ตาม หากผู้โจมตีหลอกให้ผู้ใช้อนุญาตสิทธิ์ Apple Events ผลการยินยอมนั้นกลับไม่ปรากฏใน System Settings
• ผู้ใช้สามารถเพิกถอนความยินยอมผ่านเครื่องมือ CLI tccutil ได้ แต่เครื่องมือนี้มีเอกสารจำกัดและผู้ใช้ส่วนใหญ่ยากจะรู้จัก
  • เอกสารของ Apple ที่เกี่ยวข้องมี Technical Q&A ฉบับเก่า และ IT training page

Endpoint Security และความเป็นไปได้ในการตรวจจับ

• เฟรมเวิร์ก Endpoint Security ของ Apple เพิ่งเริ่มรองรับการเฝ้าตรวจการแก้ไขฐานข้อมูล TCC
• บทความของ Objective-See ที่กล่าวถึงการเปลี่ยนแปลงนี้: Endpoint Security TCC database monitoring
• หากฟีเจอร์นี้ทำงานได้ตามคาด แอปที่ใช้เฟรมเวิร์กนี้อาจแจ้งผู้ใช้ภายหลังได้ว่าแท้จริงแล้วสิทธิ์ถูกมอบให้กับแอปใด
• อย่างไรก็ตาม ความสามารถในการตรวจจับนี้มีความหมายโดยตรงเพียงในช่วงเวลาสั้น ๆ ระหว่างที่ Apple เพิ่ม Endpoint Security event และก่อนที่ช่องโหว่จะถูกแพตช์

วิธีที่ Apple แก้ไข

• จากการวิเคราะห์ไบนารี tccd ของ macOS Sequoia 15.5 พบว่าแพตช์สุดท้ายซับซ้อนกว่าที่คาดไว้ในตอนแรก
• หลังแพตช์แล้ว ไม่สามารถสวมรอยป๊อปอัป TCC ด้วยวิธีเดียวกันนี้ได้อีก
• ดูเหมือนว่าการใช้ TCCAccessRequestIndirect กับ TCC service อื่นโดยใส่ indirect object เป็นสตริงว่างก็ถูกจำกัดด้วย
• มีการสังเกตว่าข้อความในรูปแบบที่มีช่องโหว่จะถูก tccd ทิ้งแบบเงียบ ๆ และไม่ก่อให้เกิดการทำงานใด ๆ
• แม้จากการตรวจสอบแบบง่ายจะดูเป็นแพตช์ที่ดี แต่ยังต้องมีการวิเคราะห์เพิ่มเติมเพื่อเข้าใจพฤติกรรมทั้งหมดอย่างสมบูรณ์

ลำดับเหตุการณ์ตั้งแต่การรายงานจนถึงแพตช์

• ช่องโหว่นี้เป็นบั๊กตัวที่สองที่ถูกรายงานต่อ Apple และเป็นกรณีที่ใช้เวลานานที่สุดกว่าจะมีแพตช์ในบรรดารายงานที่ Apple แก้ไขแล้ว
• กระบวนการรายงานรวมถึงการแจ้งเบื้องต้น, การที่ Apple Product Security ขอคำอธิบายเพิ่มเติม, การแชร์เส้นทาง bypass TCC แบบเต็มที่เป็นไปได้, การอัปเดตการทดสอบ PoC, การยืนยันสถานะการทำซ้ำปัญหา และการติดตามความคืบหน้าหลายครั้ง
• แพตช์แบบง่ายที่เคยเสนอคือการตรวจสอบว่าสองฟิลด์ชี้ไปยังแอปเดียวกันหรือไม่
• Apple ตอบกลับหลายครั้งว่ายังอยู่ระหว่างการตรวจสอบ ก่อนจะขอชื่อสำหรับใส่เครดิตและปล่อยแพตช์ในเวลาต่อมา
• ช่องโหว่นี้ถูกตั้งชื่อว่า “TCC, Who?”