ช่องโหว่ใหม่หลายรายการสำหรับการหลุดออกจาก sandbox บน macOS

 (jhftss.github.io)
1 คะแนน โดย GN⁺ 2024-11-09 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ในงานวิจัยการหลุดออกจาก sandbox บน macOS พบว่า PID domain XPC service ซึ่งก่อนหน้านี้ไม่ค่อยถูกมองเป็นเป้าหมาย ได้กลายเป็นพื้นผิวโจมตี และนำไปสู่การค้นพบช่องโหว่ใหม่มากกว่า 10 รายการ
  • เป้าหมายหลักไม่ใช่ Mach service ใน System/User domain แต่เป็น XPC service ประเภท Application ที่ถูกลงทะเบียนใน PID domain เมื่อโหลดแอปหรือ framework
  • ตัวอย่างช่องโหว่ประกอบด้วย CVE-2023-27944, CVE-2023-32414, CVE-2023-32404, CVE-2023-41077, CVE-2023-42961, CVE-2024-27864, CVE-2023-42977 เป็นต้น โดยบางรายการเชื่อมโยงไปถึง การบายพาส TCC, สิทธิ์ที่เกี่ยวข้องกับ SIP และผลกระทบต่อ iOS
  • จุดล้มเหลวที่เกิดซ้ำคือ service ที่ไม่ได้ถูกแยก isolation จัดการไฟล์·ไดเรกทอรี·archive·DMG โดยไม่สามารถจัดการ extended attribute quarantine, สตริงพาธ และการตรวจสอบสิทธิ์ของ client ได้อย่างปลอดภัย
  • การตอบสนองของ Apple นำไปสู่การลบ XPC service ที่มีช่องโหว่ การ normalize อินพุต การย้ายการตรวจสอบไปฝั่ง server และการกำหนดให้ต้องมี private entitlement แต่ยังเหลือรายงานอีก 5 รายการที่รอแพตช์อยู่

โมเดล sandbox ของ macOS และเป้าหมายของการหลุดออก

  • ใน macOS มี process จำนวนมาก รวมถึง service ของ Apple เองและแอปจาก third party ที่ทำงานอยู่ใน สภาพแวดล้อม sandbox ที่ถูกจำกัด
  • แม้ผู้โจมตีจะได้ remote code execution (RCE) ใน process ที่อยู่ใน sandbox ความสามารถในการรันและสิทธิ์เข้าถึงไฟล์ก็ยังถูกจำกัด ดังนั้นขั้นตอนถัดไปคือ การหลุดออกจาก sandbox เพื่อให้ได้สิทธิ์ที่กว้างขึ้น

  • App Sandbox

    • ตามข้อกำหนดของ Mac App Store แอปจำนวนมากทำงานภายใต้ข้อจำกัดของ App Sandbox
    • แอปที่อยู่ใน sandbox ต้องมี entitlement com.apple.security.app-sandbox
    • ข้อจำกัดจะถูกบังคับใช้ในขั้นตอน dyld initialization ซึ่งอยู่ก่อนฟังก์ชัน main ของแอป
    • เมื่อเข้าสู่ App Sandbox แอปจะถูกทำให้เป็น container และการทำงานกับไฟล์จะถูกจำกัดไว้ที่พาธของ data container
    • ไฟล์ที่แอปใน sandbox สร้างขึ้นจะมี extended attribute com.apple.quarantine ติดมาด้วยโดยค่าเริ่มต้น
    • ใน sandbox profile มีกฎที่ป้องกันการลบ extended attribute นี้
    • สิทธิ์ย่อยของ App Sandbox ถูกกำหนดไว้ใน /System/Library/Sandbox/Profiles/application.sb
    • เครือข่าย ฮาร์ดแวร์ filesystem และ Mach service ที่เข้าถึงได้จะถูกจำกัด
    • process ลูกที่ถูก fork จะสืบทอดข้อจำกัดของ App Sandbox จาก process แม่
    • process ที่รันผ่าน LaunchService.framework จะไม่สืบทอดข้อจำกัด เช่น สามารถใช้คำสั่ง open ของระบบเพื่อรันแอปที่ไม่อยู่ใน sandbox ได้โดยตรง

  • Service Sandbox

    • daemon service จำนวนมากของ Apple ทำงานในบริบท Service Sandbox
    • service sandbox profile ส่วนใหญ่อยู่ที่ /System/Library/Sandbox/Profiles/*.sb และ /usr/share/sandbox/*.sb
    • ข้อจำกัดของ Service Sandbox ถูกบังคับใช้แบบ manual โดยเรียก API sandbox_init_XXX ในฟังก์ชัน main ของ service
    • service ที่เข้าสู่ Service Sandbox โดยทั่วไปจะไม่ถูกทำให้เป็น container
    • ความแตกต่างสำคัญคือไฟล์ที่สร้างใน Service Sandbox โดยค่าเริ่มต้นจะ ไม่ถูกตั้งค่า quarantine
    • หากไม่เรียก API ที่เกี่ยวข้องกับ quarantine เอง ไฟล์ที่สร้างขึ้นจะไม่มี quarantine ติดมา

เส้นทางการหลุดออกจาก sandbox บน macOS ที่มีอยู่เดิม

  • การโจมตี LaunchService.framework

    • วิธีที่พบได้บ่อยเดิมวิธีหนึ่งคือการโจมตีแอปที่ไม่อยู่ใน sandbox ผ่าน LaunchService.framework
    • CVE-2021-30864 เป็นกรณีที่จัดการ environment variable $HOME กับ Terminal.app ซึ่งเป็นแอประบบที่ไม่อยู่ใน sandbox
    • เมื่อรัน Terminal payload อันตรายที่อยู่ใต้ $HOME/.profile ซึ่งควบคุมได้จะถูกรันโดยไม่มีข้อจำกัดของ sandbox
    • อีกสถานการณ์หนึ่งคือการ drop แอปใหม่ที่ไม่อยู่ใน sandbox แล้วรัน
    • อย่างไรก็ตาม แอปใหม่ที่แอปใน sandbox drop ลงมาจะถูกตั้งค่า quarantine ทำให้รันไม่ได้
    • หากสามารถ drop ไฟล์หรือโฟลเดอร์โดยไม่มี quarantine ได้ ก็สามารถบายพาส App Sandbox ได้อย่างสมบูรณ์
    • CVE-2023-32364 เป็นกรณีที่ใช้ประโยชน์จากข้อเท็จจริงที่ devfs ไม่รองรับ extended attribute เพื่อ drop โฟลเดอร์ที่ไม่มี quarantine

  • การโจมตี Mach service ที่เข้าถึงได้

    • วิธีที่พบบ่อยวิธีที่สองคือการโจมตี Mach service ที่ระบุอยู่ใน App Sandbox profile
    • ข้อมูล Mach service ของระบบถูกเก็บไว้ใน /System/Library/xpc/launchd.plist
    • สามารถใช้ API bootstrap_look_up เพื่อตรวจสอบจากแอปใน sandbox ว่าเข้าถึง Mach service เฉพาะได้หรือไม่
    • Mach service เหล่านี้อยู่ใน System domain หรือ User domain
    • จุดเริ่มต้นของงานวิจัยนี้คือมี XPC service ที่เข้าถึงได้จาก App Sandbox อยู่นอกเหนือจากสอง domain นี้ด้วย

พื้นผิวโจมตีใหม่: PID domain XPC service

  • XPC service ที่ถูกมองข้ามอยู่ใน PID domain
  • ต่างจาก XPC service ใน System/User domain ที่เคยถูกพิจารณาเป็นหลัก service เหล่านี้มี service type เป็น Application
  • XPC service ประเภท Application จะถูกเรียกใช้เมื่อแอปร้องขอ และจะปิดไปพร้อมกับแอปที่ร้องขอเมื่อแอปนั้นจบการทำงาน
  • XPC service ใน System/User domain จะเข้าถึงได้จากแอปใน sandbox เฉพาะเมื่อถูกกำหนดไว้ใน application.sb เท่านั้น
  • XPC service ทั้งหมดที่แอปและ framework ต้องการจะปรากฏใน PID domain ของแอปนั้น
  • XPC service จำนวนมากใน PID domain ไม่ได้คาดว่าจะถูกเรียกจากแอปใน sandbox จึงอาจไม่มีการตรวจ entitlement หรือการตรวจ sandbox สำหรับ XPC client ที่เข้ามา

  • กรณี SystemShoveService.xpc

    • SystemShoveService.xpc เป็น bundle XPC ภายใน private framework ของระบบชื่อ ShoveService.framework
    • service type ใน Info.plist คือ Application และ bundle identifier คือ com.apple.installandsetup.shoveservice.system
    • เมื่อโหลด /System/Library/PrivateFrameworks/ShoveService.framework จากแอปใน sandbox XPC service ที่เกี่ยวข้องจะถูกลงทะเบียนใน PID domain โดยอัตโนมัติ
    • SystemShoveService.xpc ไม่ตรวจสอบ XPC client ที่ร้องขอ จึงถูกใช้โจมตีเพื่อหลุดออกจาก App Sandbox ได้
    • service นี้มี entitlement ที่เกี่ยวข้องกับ SIP อันทรงพลังชื่อ com.apple.rootless.install จึงอาจเชื่อมโยงไปถึงการบายพาสการป้องกันของ SIP ได้ด้วย
    • ช่องโหว่นี้ถูกกำหนดเป็น CVE-2022-26712 และรายละเอียดสรุปไว้ใน บทความก่อนหน้า

  • วิธีสำรวจ

    • XPC service ทั้งหมดที่มี Service Type เป็น Application เป็นเป้าหมายที่เป็นไปได้สำหรับการหลุดออกจาก App Sandbox
    • สามารถค้นหาได้โดยไล่รายการ XPC service ใน system framework และ private framework
      • /System/Library/Frameworks
      • /System/Library/PrivateFrameworks
    • หากมี PID domain XPC service ที่ไม่ตรวจสอบ XPC client ที่เข้ามา ก็สามารถลองโจมตีด้วยวิธีต่อไปนี้
      • drop โฟลเดอร์ แอปโดยไม่มี quarantine เพื่อให้ได้การหลุดออกจาก sandbox อย่างสมบูรณ์
      • drop ไฟล์ ZIP หรือ DMG ที่มีแอปที่ไม่อยู่ใน sandbox โดยไม่มี quarantine

ช่องโหว่ 2 รายการที่มีเฉพาะในเบต้า

  • Beta-No-CVE-1: การรันคำสั่งตามอำเภอใจใน StorageKit

    • Apple บันทึกช่องโหว่นี้ไว้ใน additional recognitions แต่ไม่ได้กำหนด CVE ให้
    • ตามที่ Apple ระบุ CVE จะถูกกำหนดให้เฉพาะช่องโหว่ของซอฟต์แวร์ที่ปล่อยสู่โปรดักชันเท่านั้น และจะไม่ถูกกำหนดให้ช่องโหว่ของ ซอฟต์แวร์ beta-only
    • มีผลกระทบเฉพาะ macOS Sonoma Beta เท่านั้น
    • พาธของบริการ XPC ที่มีช่องโหว่คือ /System/Library/PrivateFrameworks/StorageKit.framework/XPCServices/storagekitfsrunner.xpc
    • บริการนี้สามารถรันได้โดยไม่มีข้อจำกัด sandbox และยอมรับ XPC client ทั้งหมดในเมธอด delegate
    • เมธอดเดียวของ SKRemoteTaskRunnerProtocol คือ runTask:arguments:withReply: ถูกออกแบบมาให้รันคำสั่งตามอำเภอใจด้วยพาธไฟล์ปฏิบัติการและอาร์กิวเมนต์ที่ระบุ
    • เนื่องจาก sandbox XPC client สามารถควบคุมพาธไฟล์ปฏิบัติการและอาร์กิวเมนต์ได้ จึงสามารถรันคำสั่งระบบตามอำเภอใจโดยไม่มีข้อจำกัด sandbox
    • Apple ได้ ลบ บริการ XPC ที่มีช่องโหว่ออกจากระบบปฏิบัติการ ทั้งหมด ก่อนการปล่อย macOS Sonoma 14.0 เวอร์ชันทางการ

  • Beta-No-CVE-2: การใช้ประโยชน์จากการสร้าง ZIP ใน AudioAnalyticsHelperService

    • ช่องโหว่นี้ก็ไม่ได้รับการกำหนด CVE ด้วยเหตุผล beta-only เช่นเดียวกัน
    • พาธของบริการ XPC ที่มีช่องโหว่คือ /System/Library/PrivateFrameworks/AudioAnalyticsInternal.framework/XPCServices/AudioAnalyticsHelperService.xpc
    • บริการนี้สามารถรันได้โดยไม่มีข้อจำกัด sandbox และยอมรับ XPC client ทั้งหมด
    • เมธอด createZipAtPath:hourThreshold:withReply: จะบีบอัดพาธตามอำเภอใจที่ XPC client ระบุ
    • หากในพาธที่ระบุไม่มีโฟลเดอร์ compressed ก็จะสร้างขึ้น ค้นหาไฟล์ .json ย้ายไปยังโฟลเดอร์นั้น แล้วสร้างไฟล์ ZIP
    • ผู้โจมตีสามารถเปลี่ยนโฟลเดอร์ compressed เป็น symlink เพื่อย้ายไฟล์ตามอำเภอใจไปยังตำแหน่งตามอำเภอใจได้
    • ไม่มีการตรวจสอบเนื้อหาของไฟล์ต้นทาง และพาธไฟล์ปลายทางต้องมีส่วนต่อท้าย .json
    • ไฟล์ ZIP ที่สร้างขึ้นใหม่จะ ไม่ถูกทำ quarantine เนื่องจากบริการไม่ได้อยู่ใน sandbox
    • Apple แพตช์ก่อนการปล่อย macOS Sonoma 14.0 โดยให้ตรวจสอบ entitlement com.apple.audioanalytics.helper.service ของ XPC client ที่เชื่อมต่อเข้ามา
    • ใน macOS รุ่นล่าสุด private AudioAnalyticsInternal.framework และบริการ XPC ที่เกี่ยวข้องถูกลบออกทั้งหมดแล้ว

CVE-2023-27944: TrialArchivingService

  • บริการที่มีช่องโหว่คือ /System/Library/PrivateFrameworks/TrialServer.framework/XPCServices/TrialArchivingService.xpc
  • บริการนี้เข้าสู่ Service Sandbox ด้วยโปรไฟล์ /System/Library/Sandbox/Profiles/com.apple.trial.TrialArchivingService.sb
  • เนื่องจากเป็น Service Sandbox ไฟล์ที่ถูกดรอปจึงไม่ถูกทำ quarantine
  • บริการยอมรับ XPC client ที่เชื่อมต่อเข้ามาทั้งหมด
  • เมธอด extractArchiveFromHandle:withArchiveName:toDirectory:destDirExtension:postExtractionCompression:completion: จะแตกไฟล์ archive ที่แอป sandbox ส่งมาไปยังตำแหน่งที่ระบุ
  • quarantine extended attribute ไม่ถูกส่งต่อไปยังคอนเทนต์ที่ถูกแตกออกมา จึงอาจนำไปสู่การดรอปไฟล์โดยไม่มี quarantine

  • เงื่อนไขการใช้ประโยชน์และการเลี่ยงผ่าน

    • หากใช้ประโยชน์จากเมธอดนี้ ไฟล์ Mach-O ภายใน archive จะสูญเสียสิทธิ์ execute หลังแตกไฟล์ จึงไม่สามารถรันได้ทันที
    • วิธีใช้ symlink แบบเดียวกับเทคนิคของ CVE-2021-30990 อาจเป็นแนวทางเลี่ยงผ่านได้
    • อย่างไรก็ตาม เมธอด XPC นี้จะแตกออกมาเฉพาะไดเรกทอรีและไฟล์ปกติเท่านั้น และไม่อนุญาตให้แตก symlink จาก archive
    • วิธีเลี่ยงผ่านวิธีหนึ่งคือแตกแอป payload ไปยัง พาธคอนเทนเนอร์ของแอป sandbox
    • แอป sandbox มีสิทธิ์อ่าน·เขียนในพาธดังกล่าว จึงสามารถสร้าง symlink โดยตรงหรือให้สิทธิ์ execute ด้วย chmod ได้
    • อีกวิธีหนึ่งคือ archive แอป payload ซ้อนสองชั้น
      • แตก ZIP ชั้นนอกด้วยเมธอด XPC ที่มีช่องโหว่
      • แตก ZIP ชั้นในด้วยคำสั่งระบบ open

  • แพตช์

    • Apple แพตช์ใน macOS Ventura 13.3 โดยให้ตรวจสอบ entitlement com.apple.TrialArchivingService.internal ของ XPC client ที่เชื่อมต่อเข้ามา
    • หากไม่มี entitlement ดังกล่าว จะปฏิเสธการเชื่อมต่อ XPC

CVE-2023-32414: ArchiveService

  • บริการที่มีช่องโหว่คือ /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/XPCServices/ArchiveService.xpc
  • บริการนี้เข้าสู่ Service Sandbox แต่ไฟล์ที่ถูกดรอป ไม่ถูกทำ quarantine
  • บริการยอมรับ XPC client ทั้งหมด
  • เมธอด unarchiveItemWithURLWrapper:… จะแตกไฟล์รายการที่แอป sandbox ส่งมาไปยังตำแหน่งที่ระบุ
  • เนื่องจากไม่ส่งต่อ quarantine extended attribute ไปยังคอนเทนต์ที่ถูกแตกออกมา แอป sandbox จึงสามารถดรอปไฟล์ตามอำเภอใจที่ไม่มี quarantine ได้
  • XPC client ถูกอิมพลีเมนต์ไว้แล้วในคลาส Objective-C DSArchiveService ของ DesktopServicesPriv.framework

  • แพตช์

    • Apple แพตช์ใน macOS Ventura 13.4 โดยให้ตรวจสอบ entitlement com.apple.private.ArchiveService.XPC ของ XPC client ที่เชื่อมต่อเข้ามา
    • หากไม่มี entitlement ดังกล่าว จะปฏิเสธการเชื่อมต่อ XPC

CVE-2023-32404: ShortcutsFileAccessHelper

  • บริการที่มีช่องโหว่คือ /System/Library/PrivateFrameworks/WorkflowKit.framework/XPCServices/ShortcutsFileAccessHelper.xpc
  • บริการนี้สามารถรันได้โดยไม่มีข้อจำกัด sandbox จึงถูกใช้ในการหลุดออกจาก App Sandbox ได้
  • code signing ยังมี TCC entitlement พิเศษสำหรับ Full Disk Access รวมอยู่ด้วย
  • ดังนั้นช่องโหว่นี้จึงสามารถใช้เพื่อเลี่ยงการป้องกันของ TCC ได้ทั้งหมดด้วย
  • บริการยอมรับ XPC client ทั้งหมด
  • เมธอดเดียวของ WFFileAccessHelperProtocol คือ extendAccessToURL:completion: ถูกออกแบบมาเพื่อมอบสิทธิ์อ่าน·เขียน URL ตามอำเภอใจให้กับ XPC client
    • ภายในจะเรียก API sandbox_extension_issue_file เพื่อออกโทเค็นการเข้าถึงไฟล์
    • URL ตามอำเภอใจถูกระบุโดย sandbox XPC client

  • แพตช์

    • Apple แพตช์ใน macOS Ventura 13.4 โดยให้ตรวจสอบ entitlement com.apple.shortcuts.file-access-helper ของ XPC client ที่เชื่อมต่อเข้ามา
    • หากไม่มี entitlement ดังกล่าว จะปฏิเสธการเชื่อมต่อ XPC

CVE-2023-41077: mscamerad-xpc และการเลี่ยงแพตช์ซ้ำ

  • บริการที่มีช่องโหว่คือ /System/Library/Frameworks/ImageCaptureCore.framework/XPCServices/mscamerad-xpc.xpc
  • บริการนี้สามารถรันได้โดยไม่มีข้อจำกัดของ sandbox จึงถูกใช้เพื่อหลุดออกจาก App Sandbox ได้
  • ใน code signing มี TCC entitlement พิเศษที่อนุญาตให้เข้าถึง Photos และ Removable Volumes ได้โดยไม่ต้องมี prompt จากผู้ใช้
  • ดังนั้นจึงสามารถเลี่ยงการป้องกันของ TCC เหล่านี้ไปพร้อมกันได้

  • ลำดับการทำงานที่มีช่องโหว่

    • ชื่อบริการพื้นฐานคือ com.apple.mscamerad-xpc
    • บริการนี้ยอมรับ XPC client ทุกตัว
    • openDevice:withReply: ของ ICXPCDeviceManagerProtocol จะเปิดและตั้งค่า MSCameraDevice ใหม่
    • ระหว่างการเริ่มต้นอุปกรณ์ใหม่ จะมีการเปิดบริการ XPC แบบไม่ระบุชื่ออีกตัวเพื่อให้บริการ routine สำหรับอุปกรณ์กล้อง
    • บริการ XPC แบบไม่ระบุชื่อนั้นก็ยอมรับ XPC client ทุกตัวเช่นกัน
    • เมธอด requestReadDataFromObjectHandle:options:withReply: ของ ICCameraDeviceProtocol จะอ่านเนื้อหาของรายการไฟล์ที่ร้องขอ แล้วส่งกลับไปยัง XPC client
    • XPC client สามารถควบคุมพาธของไฟล์ที่ร้องขอได้ ทำให้แอปที่อยู่ใน sandbox สามารถอ่านไฟล์ใดๆ นอกคอนเทนเนอร์ได้
    • เนื่องจากบริการมี TCC entitlement ที่ทรงพลัง จึงสามารถอ่าน Photos ของผู้ใช้ได้โดยไม่มี prompt จากผู้ใช้

  • การสร้างอุปกรณ์กล้องปลอม

    • MSCameraDevice สามารถจำลองได้ด้วยการสร้างและเมานต์ไฟล์ DMG
    • หากพาธไฟล์ภายในวอลุ่ม DMG ตรงกับ regular expression ที่กำหนด รายการไฟล์นั้นจะถูกทำดัชนีเป็น ICCameraFile
    • ตัวอย่างชื่อโฟลเดอร์: 123abcde, DCIM, dcIm
    • ตัวอย่างชื่อไฟล์: abcd1234.mp3, 1234E5678.HEIC
    • แอปที่อยู่ใน sandbox สามารถทริกเกอร์ปัญหาได้โดยวางไฟล์ DMG แล้วเปิดเพื่อเมานต์
    • XPC client ถูก implement ไว้แล้วในเฟรมเวิร์ก ImageCaptureCore

  • แพตช์และการเลี่ยง

    • Apple เพิ่มการตรวจสอบใหม่ใน acceptConnection: บน macOS Sonoma 14
    • หาก client มี private entitlement com.apple.private.imagecapturecore.authorization_bypass จะอนุญาต
    • หรือหาก client เป็น platform binary ก็จะอนุญาต
    • เงื่อนไข platform binary สามารถเลี่ยงได้ เพราะสามารถ inject dynamic library เข้าไปในไบนารีที่เซ็นโดย Apple ได้
      • เลือกไบนารีที่เซ็นโดย Apple แต่ไม่มี entitlement คือ /bin/ls
      • inject dylib ที่มีโค้ด exploit เดิมด้วย environment variable DYLD_INSERT_LIBRARIES
      • จากนั้นสื่อสารกับ XPC service เหมือนเดิม
    • Apple กำหนด CVE-2024-23253 ให้กับรายงานการเลี่ยงนี้
    • ใน macOS 14.4 เงื่อนไขที่สองถูกเพิ่มความเข้มงวด โดย XPC client ไม่เพียงต้องเป็น platform binary เท่านั้น แต่ยังต้องถูกเซ็นด้วย flag CS_REQUIRE_LV หรือ CS_FORCED_LV ด้วย
    • แพตช์นี้ก็ยังสามารถเลี่ยงได้
      • inject dylib เข้าไปใน /bin/ls
      • ตั้งค่า flag ที่ต้องการด้วยตนเองที่ runtime ผ่าน API csops
      • จากนั้นผ่านการตรวจสอบของ XPC service
    • Apple กำหนด CVE-2024-40831 ให้กับการเลี่ยงครั้งที่สองนี้
    • ใน macOS Sequoia 15 มีการแพตช์อีกครั้งให้อนุญาตเฉพาะ XPC client ที่มี private entitlement com.apple.private.imagecapturecore.authorization_bypass เท่านั้น

CVE-2023-42961: intents_helper

  • ช่องโหว่นี้สามารถถูกใช้โจมตีได้บน iOS ด้วย
  • บริการที่มีช่องโหว่คือ /System/Library/Frameworks/Intents.framework/XPCServices/intents_helper.xpc
  • บริการนี้สามารถรันได้โดยไม่มีข้อจำกัดของ sandbox และยอมรับ XPC client ทุกตัว
  • เนื่องจาก path traversal (การไล่พาธ) ในฟังก์ชัน filePathForImageWithFileName จึงสามารถเข้าถึงพาธใดๆ ได้
  • พารามิเตอร์ fileName เป็นสตริงใดๆ ที่ XPC client สามารถควบคุมได้

  • เมธอดที่ได้รับผลกระทบ

    • ฟังก์ชันที่มีช่องโหว่สามารถเข้าถึงได้จาก XPC method สองตัว
    • retrieveImageWithIdentifier:completion: สามารถถูกใช้เพื่ออ่านไฟล์ใดๆ ที่มีนามสกุล .png
    • ข้อมูลที่อ่านได้จะถูกเก็บในตัวแปรสมาชิกของอินสแตนซ์ INImage แล้วส่งกลับไปยัง XPC client
    • purgeImageWithIdentifier:completion: สามารถถูกใช้เพื่อลบพาธไฟล์ใดๆ ได้

  • แพตช์

    • Apple แพตช์ใน macOS Sonoma 14.0 โดยทำ normalization กับสตริงอินพุตจาก XPC client
    • ตัดอักขระพิเศษที่ใช้ใน path traversal ออก

CVE-2024-27864: diskimagescontroller

  • รายการ CVE นี้ยังรอการเปิดเผยต่อสาธารณะในขณะที่เขียนบทความ
  • บริการที่มีช่องโหว่คือ /System/Library/PrivateFrameworks/DiskImages2.framework/XPCServices/diskimagescontroller.xpc
  • บริการนี้มี entitlement com.apple.diskimages.creator-uc ใน code signing จึงสามารถทำงานที่มีอำนาจสูงได้
  • ความสามารถหลักของ entitlement นี้มีสองอย่าง
    • สื่อสารกับ /usr/libexec/diskimagesiod ซึ่งมี FDA entitlement และทำงาน attach จริง
    • เชื่อมต่อกับ IOKit service AppleDiskImagesController เพื่อสร้างอุปกรณ์สำหรับไฟล์ DMG และจัดการ quarantine

  • สาเหตุของช่องโหว่

    • บริการนี้ยอมรับ XPC client ทุกตัว
    • เมธอด attachWithParams:reply: ของ DIControllerProtocol เป็นจุดโจมตี
    • ภายในมีการเรียก checkAttachEntitlementWithError แต่ฟังก์ชันนี้กลับคืนค่า TRUE เสมอ ต่างจากชื่อของมัน
    • ใน DiskImages2.framework มี XPC client ที่ implement ไว้แล้วด้วยคลาส Objective-C DIAttachParams
    • โค้ด client ของเฟรมเวิร์กตรวจสอบว่า URL อินพุตอยู่ในสถานะ quarantine หรือไม่
    • หาก URL อินพุตอยู่ในสถานะ quarantine จะตั้งค่าพารามิเตอร์ quarantine ก่อน attach และพารามิเตอร์นี้จะแจ้งให้ XPC service ทำ quarantine กับอุปกรณ์เป้าหมาย
    • หากสร้าง XPC client เอง จะสามารถข้ามการตั้งค่าพารามิเตอร์ quarantine และเรียก attachWithParams:reply: ได้โดยตรง
    • ผลคือสามารถ attach ไฟล์ DMG ที่ถูก quarantine โดยไม่ทำ quarantine กับอุปกรณ์ที่สอดคล้องกันได้

  • แพตช์

    • Apple ย้ายตรรกะการตรวจสอบจาก ฝั่ง client ไปยังฝั่ง server ใน macOS Sonoma 14.4
    • หากพาธไฟล์อินพุตอยู่ในสถานะ quarantine ฝั่ง server จะทำ quarantine กับอุปกรณ์ที่สอดคล้องกันโดยตรง

CVE-2023-42977: PerfPowerServicesSignpostReader

  • บริการที่มีช่องโหว่คือ /System/Library/PrivateFrameworks/PowerlogCore.framework/XPCServices/PerfPowerServicesSignpostReader.xpc
  • บริการนี้สามารถรันได้โดยไม่มีข้อจำกัดของ sandbox และยอมรับไคลเอนต์ XPC ทั้งหมด
  • XPCSignpostReaderProtocol มี 6 เมธอด แต่ Apple implement ไว้เพียงเมธอดเดียวคือ submitSignpostDataWithConfig:withReply: ส่วนอีก 5 เมธอดเป็น implementation ว่าง
  • ลอจิกหลักของเมธอดนี้คือรวบรวมข้อมูลล็อกแล้ว archive เป็นไฟล์ gzip
  • เคยสามารถ hijack พาธ powerlog ไปยังพาธใดก็ได้ด้วยสตริง tagUUID ที่ไคลเอนต์ XPC ควบคุม

  • การลบพาธใดก็ได้

    • ภายในฟังก์ชันมีการเรียก archiveDirectoryAt:deleteOriginal: เพื่อลบพาธ powerlog
    • หากใส่สตริง path traversal ใน TagUUID ก็จะได้ primitive สำหรับลบพาธใดก็ได้

  • การสร้างไดเรกทอรีใดก็ได้และการหลุดออกจาก sandbox อย่างสมบูรณ์

    • ฟังก์ชัน createSignpostFile: สร้างไดเรกทอรีในพาธ powerlog
    • ด้วยวิธีนี้จึงสามารถสร้าง ไดเรกทอรีใดก็ได้ที่ไม่มี extended attribute quarantine
    • primitive สำหรับสร้างไดเรกทอรีใดก็ได้ที่ไม่มี quarantine อาจนำไปสู่การหลุดออกจาก sandbox อย่างสมบูรณ์
    • ในบทความใช้เทคนิคของ CVE-2023-32364
      • สร้างโฟลเดอร์ .app ที่ไม่มี quarantine
      • สร้าง symlink ไปยัง /bin/bash ใต้ Contents/MacOS
      • ตั้งค่า BASH_ENV ใน LSEnvironment
      • รันด้วย open ./poc.app

  • แพตช์

    • Apple แพตช์ใน macOS Sonoma 14.0 ให้ normalize สตริง UUID ของไคลเอนต์ XPC
    • จัดการให้ฟังก์ชันออกทันทีหากสตริงอินพุตไม่ใช่ UUID ที่ถูกต้อง

รูปแบบที่เกิดซ้ำ

  • attack surface หลักไม่ใช่บริการ XPC ใน System หรือ User domain แต่เป็น บริการ XPC ใน PID domain ภายในระบบและ private framework
  • บริการ XPC ที่มี Service Type เป็น Application สามารถถูกลงทะเบียนใน PID domain ของแอป sandbox ได้เพียงแค่โหลด framework
  • บริการที่มีช่องโหว่จำนวนมากไม่ได้คาดว่าจะมีการเรียกจากไคลเอนต์ sandbox จึงละเว้นการตรวจสอบต่อไปนี้
    • การตรวจสอบ entitlement ของไคลเอนต์ XPC
    • การตรวจสอบว่าเป็นไคลเอนต์ sandbox หรือไม่
    • การ normalize พาธอินพุต
    • การตรวจสอบสถานะ quarantine ฝั่งเซิร์ฟเวอร์
  • เงื่อนไขที่ถูกนำไปใช้ซ้ำในการโจมตีมีดังนี้
    • การวางไฟล์หรือโฟลเดอร์ที่ไม่มี quarantine อาจนำไปสู่การหลุดออกจาก sandbox อย่างสมบูรณ์
    • หาก extended attribute quarantine หายไประหว่างการแตกไฟล์บีบอัด อาจนำไปสู่การ bypass Gatekeeper และการหลุดออกจาก sandbox
    • ไฟล์ที่ Service Sandbox สร้างขึ้นโดยค่าเริ่มต้นจะไม่ถูก quarantine
  • ยังมีรายงานที่รอแพตช์อยู่อีก 5 รายการ

ความเห็นเพิ่มเติมเกี่ยวกับ App Sandbox และ Service Sandbox

  • สำหรับรายงานหนึ่ง Apple ตัดสินว่าเป็น expected behavior เนื่องจากแอปพลิเคชันที่เพิ่งรันไม่ได้อยู่ในบริบทของโปรเซสปัจจุบัน และไม่สามารถแชร์ entitlement หรือสิทธิ์ของโปรเซสปัจจุบันได้
  • ใน App Sandbox ไฟล์ที่ถูก drop จะถูก quarantine โดยค่าเริ่มต้น
  • ใน Service Sandbox ไฟล์ที่ถูก drop จะไม่ถูก quarantine โดยค่าเริ่มต้น
  • สรุปว่า ประเด็นที่โปรเซสที่เพิ่งรันไม่ได้อยู่ในบริบทการรันของบริการปัจจุบัน จึงไม่แชร์ entitlement หรือ privilege ของบริการนั้น ไม่ถือเป็น flaw โดยตัวมันเอง
  • ในทางกลับกัน การที่ผู้โจมตีได้ RCE ในบริบทของบริการที่ถูกจำกัดด้วย sandbox แล้ว drop และรันแอปใหม่ที่ไม่อยู่ใน sandbox เพื่อหลุดออกจากข้อจำกัด sandbox ของบริการเป้าหมายได้นั้น อาจถือเป็น flaw
    • มีการกล่าวถึง IMTranscoderAgent ซึ่งเคยเป็นเป้าหมายของ 0-click exploit ของ NSO Group เป็นตัวอย่าง
  • com.apple.WebDriver.HTTPService.xpc ถูกยกเป็นตัวอย่างของการเรียก API WBSEnableSandboxStyleFileQuarantine แบบ manual
  • สรุปว่าการหลุดจาก App Sandbox ไปยัง Service Sandbox บน macOS แทบจะเท่ากับการไปสู่สถานะ Non Sandbox

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

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

 
GN⁺ 2024-11-09
ความคิดเห็นบน Hacker News

  • การรับมือด้วยการแพตช์ บริการ XPC ทีละตัวตรงนี้ดูแปลกอยู่หน่อย
    มันดูเหมือนเป็นปัญหาการออกแบบของตัวแซนด์บ็อกซ์เอง และก็น่าสงสัยว่าทำไมบริการ XPC ที่ดูเหมือนใช้ภายในแอปถึงถูกเข้าถึงจากแอปที่อยู่ในแซนด์บ็อกซ์ได้มากขนาดนี้

    • ใช่ น่าจะเป็น การประนีประนอม จากการที่ macOS เอาสิ่งนี้มาใส่เพิ่มทีหลัง โดยพยายามไม่ให้ของเดิมที่สืบทอดมาจาก UNIX และ NeXTSTEP พัง
      ฝั่ง Windows ก็มีมาตรการคล้าย ๆ กันมากมาย เช่น แซนด์บ็อกซ์ WinRT, แซนด์บ็อกซ์แอป Win32, secure kernel, การป้องกันไดรเวอร์ ฯลฯ แต่ถ้าต้องให้ไฟล์ปฏิบัติการเดียวรันข้ามหลายคอนฟิกได้ ก็ย่อมมีช่องว่างจากความเข้ากันได้ย้อนหลัง
      ระบบปฏิบัติการมือถือทำได้ง่ายกว่ามาก เพราะไม่มีภาระความเข้ากันได้ย้อนหลัง และสามารถจำกัดโมเดลการรันได้อย่างเข้มงวด

  • MacOS ควรมีอะไรอย่างคอนเทนเนอร์ Darwin แบบอิง capability มากกว่าวิธีที่ดูเหมือนก้อน รายการบล็อก ขนาดใหญ่

    • https://github.com/darwin-containers
      https://news.ycombinator.com/item?id=37655477
      ยังไม่มีโมเดลความปลอดภัยที่ทำงานได้ดีบนเดสก์ท็อป
      อย่างที่คอมเมนต์อื่นว่า iOS ไม่มีเศษซากเก่า ๆ จึงสามารถให้โมเดลความปลอดภัยที่สมเหตุสมผลได้
      ในทางกลับกัน ถ้า Telegram ขอแชร์รายชื่อติดต่อและรูปภาพทั้งหมด ผู้คนก็ยอมอนุญาตจริง ๆ

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

    • เพราะระบบจำนวนมากแบบนี้ไม่ได้ถูกออกแบบให้ปลอดภัยอย่างถูกต้องตั้งแต่ต้นจนจบ
      วิธีที่ถูกต้องมักล้มเหลวในตลาดเพราะความเข้ากันได้ย้อนหลัง หรือเพราะนักพัฒนาไม่ยอมรับฟีเจอร์ไปใช้ แซนด์บ็อกซ์ WinRT เป็นตัวอย่างแบบนั้น
      ความปลอดภัยบนโทรศัพท์ทำได้ง่ายกว่า เพราะไม่ต้องกังวลเรื่องความเข้ากันได้ย้อนหลัง และจนถึงตอนนี้นักพัฒนาที่อยากเข้าร่วมก็จำเป็นต้องทำตามเพราะการคัดกรองของ App Store
    • ท้ายที่สุดแล้ว ความปลอดภัยไปด้วยกันได้ยากกับความเข้ากันได้ย้อนหลัง
      ระบบปฏิบัติการทั้งหมดที่ใช้งานอยู่ในปัจจุบัน หากต้องการให้ปลอดภัยไปจนถึงศตวรรษหน้า ก็ต้องสร้างใหม่ตั้งแต่ต้น และต้องทิ้งโค้ดจำนวนมากระหว่างทาง นั่นคือราคาที่ต้องจ่าย
    • ที่พูดถึงกฎหมายภาษีเนเธอร์แลนด์นี่น่าสนใจดี แม้จะบอกว่า “ช่องโหว่ให้ใช้ประโยชน์” บางส่วนถูกใส่มาโดยตั้งใจ ก็คงไม่ใช่เรื่องที่ถกเถียงกันมากนัก
      อาจคาดเดาได้ว่ามีแรงผลักดันที่เข้มแข็งบางกลุ่มที่อยากยัดช่องโหว่เข้าไปในคอมพิวติ้งสำหรับผู้บริโภคให้มากขึ้น
      ตัวอย่างที่โด่งดังแต่ละกรณีมีดังนี้
      https://en.wikipedia.org/wiki/Dutch_Sandwich
      https://en.wikipedia.org/wiki/Intel_Management_Engine#Assert...

  • MacOS หรือก็คือ NeXTstep ถูกสร้างมาตั้งแต่แรกให้เป็น ระบบปฏิบัติการที่เปิดกว้างและขยายได้สูงมาก
    มีวิธีเพิ่มส่วนขยายหรือ hook ของบุคคลที่สามมากจนนับไม่ถ้วน และซอฟต์แวร์สามารถถูกเข้าถึงได้จากหลาย runtime ดังนั้นในยุคนั้น การที่ทั้งหมดนี้ทำงานร่วมกันได้อย่างราบรื่นจึงเป็นความสำเร็จทางเทคนิคที่น่าประทับใจ
    Java, Mac แบบคลาสสิก, X11 และฐานโค้ด NeXTstep รันร่วมกันได้อย่างไม่มีปัญหาเพราะจุดเข้าของส่วนขยายหลายจุดในเคอร์เนล
    นอกจากนี้แพลตฟอร์มยังมี API ที่ช่วยให้แอปสื่อสารกันได้โดยไม่มีปัญหา
    แต่ Apple ค่อย ๆ ถอยออกจากปรัชญานั้น และปิดระบบลงเรื่อย ๆ เป็นเส้นทางที่น่าสนใจทีเดียว

  • SBPL (sandbox profile language) น่าสนใจ รายละเอียดเพิ่มเติมอยู่ที่นี่: https://github.com/0xbf00/simbple
    สงสัยว่ามี Scheme interpreter อยู่ที่ไหนสักแห่งใน macOS เพื่อจัดการสิ่งนี้หรือเปล่า
    ป.ล. ดูเหมือนว่า sandbox-exec จะเป็นตัวที่ทำงานนี้ ดูเพิ่มเติม: https://reverse.put.as/wp-content/uploads/2011/09/Apple-Sand...

  • เป็นการค้นพบที่น่าประทับใจ อย่างที่บทความบอกเป็นนัย ดูมีความเป็นไปได้สูงมากว่ายังมีข้อบกพร่องคล้าย ๆ กันหลงเหลืออยู่ในโลกจริง
    ถ้า Apple ไม่ออกแบบแนวทางการเสริมความแข็งแกร่งให้บริการเหล่านี้ใหม่ ก็คงจะมี CVE ที่เกี่ยวข้องกับ XPC ออกมาอย่างต่อเนื่อง

  • ทั้งชอบและเกลียดแซนด์บ็อกซ์
    มันเป็น แนวป้องกันชั้นที่สอง ที่ยอดเยี่ยม แต่องค์กรใหญ่ ๆ มักปฏิเสธการแก้ช่องโหว่ remote code execution หากช่องโหว่นั้นไม่สามารถหลุดออกจากแซนด์บ็อกซ์ไปทำอะไรที่มีความหมายได้ ดังนั้นแซนด์บ็อกซ์จึงถูกใช้เหมือนแนวป้องกันหลัก ซึ่งเป็นเรื่องน่าเศร้า

    • ไม่รู้ว่าที่ว่า “ถ้าหลุดออกจากแซนด์บ็อกซ์ไม่ได้ก็ปฏิเสธการแก้ช่องโหว่ remote code execution” นี่หมายถึงใคร
      เท่าที่รู้ Apple, Microsoft, Google ต่างก็มี bug bounty และให้รางวัลสูงกว่าสำหรับการหลุดแซนด์บ็อกซ์ แต่ก็ยังจ่ายรางวัลให้ช่องโหว่ที่ถูกแซนด์บ็อกซ์กันไว้
      ทุกคนรู้ดีว่าผู้โจมตีจะเก็บช่องโหว่ remote code execution ที่ตอนนี้ยังใช้ไม่ได้ไว้ แล้วนำมาใช้ร่วมกันเมื่อพบวิธีหลุดแซนด์บ็อกซ์

  • อาจจะออกนอกประเด็นไปบ้าง แต่ถ้ามีผู้เชี่ยวชาญด้านแซนด์บ็อกซ์คนไหนรู้กลยุทธ์ในการเลี่ยงข้อจำกัด maximum "pattern serialization length" ผมปวดหัวกับประเด็นนี้มานานพอสมควรแล้ว: https://github.com/NixOS/nix/issues/4119
    น่าเสียดายที่ sandbox-exec แทบไม่มีเอกสารเลย และยังมีข่าวว่าจะถูกเลิกใช้ด้วย ทำให้การแก้ปัญหานี้ค่อนข้างชวนปวดหัว

  • ใน macOS มีวิธีเลี่ยงออกมาไม่รู้จบ เพราะระบบปฏิบัติการนี้ไม่ได้ถูกออกแบบมาเพื่อ สิทธิ์แบบละเอียด แบบนี้ตั้งแต่แรก
    จะเอาไปแปะทีหลังบนเทคโนโลยี Mac OS รุ่นเก่าและ NeXTSTEP เฉย ๆ ไม่ได้
    ถึงผมจะไม่ใช่นักวิจัยความปลอดภัย เป็นแค่นักพัฒนาแอปเก่า ๆ แต่ก็ยังเคยเจอวิธีเลี่ยงหลายอย่างด้วยตัวเอง เรียกว่ารู้ว่าศพถูกฝังไว้ตรงไหน
    แต่สุดท้ายก็เลิกหาไปแล้ว ระบบรายงานช่องโหว่ด้านความปลอดภัยของ Apple เละเทะไปหมด และดูเหมือนจะสนใจแค่การปิดปากให้นานที่สุดเท่าที่ทำได้ เสียเวลาเปล่า
    โดยรวมแล้ว macOS ให้ความรู้สึกเหมือนตกเป็นเหยื่อของ ละครความปลอดภัย ซอฟต์แวร์ที่ถูกทำให้อ่อนแอลงและการขอสิทธิ์ไม่รู้จบทำร้ายทั้งผู้ใช้และนักพัฒนาที่ถูกต้องตามกฎหมาย ขณะที่ผู้โจมตีจริง ๆ สามารถเลี่ยงได้ง่าย ๆ เมื่อต้องการ คล้ายกับโฆษณาล้อเลียน Windows Vista ของ Apple ในอดีต

    • ดูเหมือนนักวิจัยที่เขียนบทความนี้จะสามารถทำให้มีการแพตช์ช่องโหว่จำนวนมากพร้อมเครดิตได้สำเร็จพอสมควร เพียงแต่ว่า CVE บางรายการในนี้ดูเหมือนจะมีอายุหลายปีแล้ว
      การที่บริษัทต้องการเวลาให้มากที่สุดในการแก้บั๊กก็เป็นส่วนหนึ่งของเกมเหมือนกัน บริษัทอื่น ๆ อยากให้เปิดเผยช่องโหว่ที่พบโดยเร็วที่สุดจริงหรือ? ในเมื่อควบคุมไม่ได้ว่าผู้ใช้จะอัปเกรดเร็วแค่ไหน การชะลอการเปิดเผยจึงดีกับผู้ใช้ปลายทางเสมอ และควรสำคัญกว่าความต้องการประชาสัมพันธ์ของนักวิจัย
      สถาปัตยกรรมแซนด์บ็อกซ์ของ Apple โดยปกติดูเหมือนออกแบบมาค่อนข้างดี กรณีนี้น่าจะมีปัญหาบางอย่างเกิดขึ้นที่สถาปัตยกรรมหรือการสื่อสาร
      การมีวิธีเลี่ยงก็เป็นเพราะเราคาดหวังฟีเจอร์จากระบบปฏิบัติการเดสก์ท็อปมากเกินไปด้วย ระบบปฏิบัติการเดสก์ท็อปถือได้ว่าเป็นระบบปฏิบัติการที่ประณีตและซับซ้อนกว่าแพลตฟอร์มเซิร์ฟเวอร์มาก เหตุผลเดียวกันนี้ทำให้เว็บเบราว์เซอร์มี CVE จำนวนมาก เพราะเราต้องการทั้งความปลอดภัยและฟีเจอร์ จึงย่อมมีจุดกึ่งกลางที่ทั้งสองอย่างชนกันอย่างหลีกเลี่ยงไม่ได้
    • ตรงข้ามกับคำพูดที่ว่า “จะเอาไปแปะทีหลังบนเทคโนโลยี Mac OS รุ่นเก่าและ NeXTSTEP เฉย ๆ ไม่ได้” Apple เป็นเจ้าของทั้งสแต็ก จึงทำได้และก็ทำมาจริง
      สิ่งที่พิสูจน์คือการที่ตลอด 20 ปีที่ผ่านมา Apple ค่อย ๆ เสริมความแข็งแกร่งให้ซอฟต์แวร์และฮาร์ดแวร์ของ macOS
      สำหรับผู้ใช้ปลายทาง ส่วนใหญ่เป็นการเปลี่ยนแปลงแบบค่อยเป็นค่อยไปจนแทบไม่ทันสังเกต แต่เหล่านักพัฒนา macOS รู้ซึ้งดีถึงประเด็นด้านความปลอดภัยที่ต้องรับมือทั้งในการอัปเดตใหญ่และอัปเดตย่อย ตัวอย่างเช่น
      https://eclecticlight.co/2024/08/…
      https://eclecticlight.co/2024/08/…
      https://eclecticlight.co/2024/08/…
      https://eclecticlight.co/2024/09/…
    • ภาระจากของเก่า แบบนี้ดูเหมือนจะมีอยู่ในระบบปฏิบัติการกระแสหลักทุกตัว
      มีระบบที่อิง capability อยู่ แต่ไม่มีตัวไหนที่ถูกใช้อย่างแพร่หลายจริง ๆ
      ผมก็ไม่แน่ใจว่าทางออกคืออะไร แต่ความพยายามเพิ่มความปลอดภัยเข้าไปก็ดูดีกว่าการไม่ทำอะไรเลยจนช่องโหว่ในแอปพลิเคชันเพียงจุดเดียวกลายเป็นการยึดบัญชีผู้ใช้ทั้งหมดได้ทันที
    • ถ้า “ไม่สามารถเพิ่มทีหลังบน Mac OS รุ่นเก่าได้” แล้ว SELinux ทำได้ อะไรคือสิ่งที่ขวาง MacOS โดยพื้นฐาน?
    • เหตุผลของข้อจำกัดแบบนี้คือเพื่อทำให้นักพัฒนาภายนอกแข่งขันกับผลิตภัณฑ์ของ Apple ได้ยากขึ้น

  • XPC services ที่หลุดรอดในโดเมน pid เป็นวิธีที่ชาญฉลาดในการเลี่ยงข้อจำกัดแซนด์บ็อกซ์ของ macOS
    ทริกฉีด dyld เพื่อเลี่ยงการตรวจสิทธิ์ก็ดูเนียนดี
    แพตช์ของ Apple ในจุดนี้ให้ความรู้สึกเหมือนเป็นการแก้เฉพาะหน้า และอาจต้องปรับวิธีการทำงานของการสืบทอดแซนด์บ็อกซ์อย่างจริงจัง