कई नए macOS sandbox escape भेद्यताएँ

 (jhftss.github.io)
1 पॉइंट द्वारा GN⁺ 2024-11-09 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • macOS sandbox escape रिसर्च में अब तक अपेक्षाकृत कम देखी गई PID domain XPC services एक attack surface के रूप में सामने आईं, जिससे 10 से अधिक नई vulnerabilities मिलीं
  • मुख्य target System/User domain की Mach services नहीं, बल्कि app या framework लोड होने पर PID domain में रजिस्टर होने वाली Application type XPC services हैं
  • प्रभावित मामलों में CVE-2023-27944, CVE-2023-32414, CVE-2023-32404, CVE-2023-41077, CVE-2023-42961, CVE-2024-27864, CVE-2023-42977 आदि शामिल हैं, जिनमें से कुछ TCC bypass, SIP-संबंधित privileges, और iOS impact तक जुड़ते हैं
  • बार-बार दिखी failure point यह थी कि non-sandboxed services फाइल, directory, archive और DMG को प्रोसेस करते समय quarantine extended attributes, path strings, और client privilege verification को सुरक्षित ढंग से हैंडल नहीं कर पा रहीं थीं
  • Apple की प्रतिक्रिया में कमजोर XPC services को हटाना, input normalization, server-side verification को पहले लागू करना, और private entitlement की आवश्यकता शामिल थी, लेकिन अभी भी 5 reports patch का इंतज़ार कर रही हैं

macOS sandbox मॉडल और escape का लक्ष्य

  • macOS में Apple की अपनी services और third-party apps सहित कई processes सीमित sandbox environment में चलते हैं
  • अगर attacker को sandboxed process में remote code execution (RCE) मिल भी जाए, तब भी execution capability और file access permissions सीमित रहती हैं, इसलिए अगला कदम ज्यादा व्यापक permissions पाने के लिए sandbox escape होता है

  • App Sandbox

    • Mac App Store की requirements के कारण कई apps App Sandbox restrictions के साथ चलते हैं
    • sandboxed app के पास com.apple.security.app-sandbox entitlement होना चाहिए
    • restrictions ऐप के main function से पहले dyld initialization चरण में लागू हो जाती हैं
    • App Sandbox में प्रवेश करने के बाद app containerized हो जाता है, और file operations data container path तक सीमित हो जाते हैं
    • sandboxed app द्वारा बनाई गई files पर डिफ़ॉल्ट रूप से com.apple.quarantine extended attribute लगती है
    • sandbox profile में इस extended attribute को हटाने से रोकने वाले rules होते हैं
    • App Sandbox की detailed permissions /System/Library/Sandbox/Profiles/application.sb में परिभाषित हैं
    • network, hardware, filesystem, और accessible Mach services सीमित रहते हैं
    • fork किए गए child processes parent की App Sandbox restrictions inherit करते हैं
    • LaunchService.framework से execute किए गए processes restrictions inherit नहीं करते; उदाहरण के लिए system open command से non-sandboxed app को सीधे चलाया जा सकता है

  • Service Sandbox

    • Apple की कई daemon services Service Sandbox context में चलती हैं
    • service sandbox profiles मुख्य रूप से /System/Library/Sandbox/Profiles/*.sb और /usr/share/sandbox/*.sb में होती हैं
    • Service Sandbox restrictions service के main function में sandbox_init_XXX API कॉल करके manually लागू की जाती हैं
    • Service Sandbox में गई services आम तौर पर containerized नहीं होतीं
    • एक महत्वपूर्ण अंतर यह है कि Service Sandbox में बनाई गई files पर डिफ़ॉल्ट रूप से quarantine apply नहीं होता
    • जब तक quarantine-संबंधित API को manually कॉल न किया जाए, बनी हुई files पर quarantine नहीं लगेगा

macOS sandbox escape के मौजूदा रास्ते

  • LaunchService.framework attack

    • पहले से प्रचलित आम तरीकों में से एक LaunchService.framework के जरिए non-sandboxed apps को target करना है
    • CVE-2021-30864 में system non-sandboxed app Terminal.app के लिए $HOME environment variable को manipulate किया गया था
    • Terminal launch होने पर नियंत्रित किए जा सकने वाले $HOME/.profile के अंदर का malicious payload sandbox restrictions के बिना execute हो गया
    • एक दूसरा scenario नया non-sandboxed app drop करके उसे चलाने का है
    • लेकिन sandboxed app द्वारा नया drop किया गया app quarantine में चला जाता है, इसलिए उसका execution block हो जाता है
    • अगर quarantine के बिना file या folder drop किया जा सके, तो App Sandbox को पूरी तरह bypass किया जा सकता है
    • CVE-2023-32364 में devfs द्वारा extended attributes को support न करने का फायदा उठाकर quarantine-रहित folder drop किया गया था

  • Accessible Mach services पर attack

    • दूसरा आम तरीका App Sandbox profile में सूचीबद्ध Mach services को target करना है
    • system की Mach service जानकारी /System/Library/xpc/launchd.plist में stored होती है
    • bootstrap_look_up API से sandboxed app के भीतर किसी specific Mach service की accessibility चेक की जा सकती है
    • ऐसी Mach services System domain या User domain में मौजूद होती हैं
    • इस रिसर्च की शुरुआत इस बिंदु से हुई कि App Sandbox से accessible XPC services इन दो domains के बाहर भी मौजूद हैं

नया attack surface: PID domain XPC services

  • नज़रअंदाज़ की गई XPC services PID domain में मौजूद हैं
  • आम तौर पर देखी जाने वाली System/User domain XPC services के विपरीत, इनका service type Application होता है
  • Application type XPC services app request पर launch होती हैं और request करने वाला app बंद होते ही साथ में बंद हो जाती हैं
  • System/User domain की XPC services तक sandboxed app से पहुँच केवल तभी संभव होती है जब वे application.sb में defined हों
  • app और framework को जिन XPC services की जरूरत होती है, वे संबंधित app के PID domain में दिखाई देती हैं
  • PID domain की कई XPC services यह मानकर नहीं चलतीं कि उन्हें sandboxed app कॉल करेंगे, इसलिए incoming XPC clients के लिए entitlement checks या sandbox checks नहीं हो सकते

  • SystemShoveService.xpc का मामला

    • SystemShoveService.xpc system private ShoveService.framework के अंदर का XPC bundle है
    • Info.plist में इसका service type Application है, और bundle identifier com.apple.installandsetup.shoveservice.system है
    • अगर sandboxed app /System/Library/PrivateFrameworks/ShoveService.framework को लोड करे, तो संबंधित XPC service अपने-आप PID domain में रजिस्टर हो जाती है
    • SystemShoveService.xpc request करने वाले XPC client की जाँच नहीं करती थी, इसलिए इसका उपयोग App Sandbox escape के लिए किया जा सकता था
    • इस service के पास com.apple.rootless.install नाम का शक्तिशाली SIP-संबंधित entitlement था, जिससे SIP protection bypass भी संभव हो सकता था
    • इस vulnerability को CVE-2022-26712 सौंपा गया था, और विस्तृत जानकारी पिछली पोस्ट में दी गई है

  • खोजने का तरीका

    • जिन भी XPC services का Service Type Application है, वे App Sandbox escape के संभावित targets हैं
    • system frameworks और private frameworks में XPC services enumerate करके इन्हें खोजा जा सकता है
      • /System/Library/Frameworks
      • /System/Library/PrivateFrameworks
    • अगर कोई PID domain XPC service incoming XPC clients की जाँच नहीं करती, तो निम्न तरीकों से attack की कोशिश की जा सकती है
      • quarantine के बिना app folder drop करके पूर्ण sandbox escape हासिल करना
      • non-sandboxed app वाली ZIP या DMG file को quarantine के बिना drop करना

केवल beta वाली 2 भेद्यताएँ

  • Beta-No-CVE-1: StorageKit में मनमाना command execution

    • Apple ने इस भेद्यता को additional recognitions में दर्ज किया, लेकिन CVE आवंटित नहीं किया
    • Apple के अनुसार, CVE केवल production में release किए गए software vulnerabilities को दिया जाता है, और beta-only software भेद्यताओं को नहीं
    • इसका प्रभाव केवल macOS Sonoma Beta versions पर था
    • भेद्य XPC service path /System/Library/PrivateFrameworks/StorageKit.framework/XPCServices/storagekitfsrunner.xpc है
    • यह service sandbox restrictions के बिना चल सकती थी और delegate method में सभी XPC clients को allow करती थी
    • SKRemoteTaskRunnerProtocol का एकमात्र method runTask:arguments:withReply: दिए गए executable path और arguments के साथ मनमाने commands चलाने के लिए design किया गया था
    • executable path और arguments को sandboxed XPC client नियंत्रित कर सकता था, इसलिए sandbox restrictions के बिना मनमाने system commands चलाए जा सकते थे
    • Apple ने macOS Sonoma 14.0 की final release से पहले इस भेद्य XPC service को OS से पूरी तरह हटा दिया

  • Beta-No-CVE-2: AudioAnalyticsHelperService के ZIP creation का दुरुपयोग

    • इस भेद्यता को भी उसी beta-only कारण से CVE नहीं दिया गया
    • भेद्य XPC service path /System/Library/PrivateFrameworks/AudioAnalyticsInternal.framework/XPCServices/AudioAnalyticsHelperService.xpc है
    • यह service sandbox restrictions के बिना चल सकती थी और सभी XPC clients को allow करती थी
    • createZipAtPath:hourThreshold:withReply: method XPC client द्वारा दिए गए मनमाने path को compress करता है
    • यदि दिए गए path पर compressed folder नहीं हो, तो उसे बनाया जाता है, फिर .json files खोजकर उस folder में ले जाया जाता है और उसके बाद ZIP file बनाई जाती है
    • हमलावर compressed folder को symlink से बदलकर मनमानी files को मनमाने स्थान पर move कर सकता है
    • source file contents की जाँच नहीं की जाती, और target file path में .json suffix होना चाहिए
    • नई बनाई गई ZIP file पर quarantine लागू नहीं होता, क्योंकि service sandboxed नहीं थी
    • Apple ने macOS Sonoma 14.0 release से पहले patch किया ताकि incoming XPC clients के com.apple.audioanalytics.helper.service entitlement की जाँच की जाए
    • नवीनतम macOS में private AudioAnalyticsInternal.framework और संबंधित XPC service को पूरी तरह हटा दिया गया है

CVE-2023-27944: TrialArchivingService

  • भेद्य service /System/Library/PrivateFrameworks/TrialServer.framework/XPCServices/TrialArchivingService.xpc है
  • यह service /System/Library/Sandbox/Profiles/com.apple.trial.TrialArchivingService.sb profile के साथ Service Sandbox में चलती है
  • Service Sandbox होने के कारण dropped files पर quarantine लागू नहीं होता
  • यह service सभी incoming XPC clients को allow करती है
  • extractArchiveFromHandle:withArchiveName:toDirectory:destDirExtension:postExtractionCompression:completion: method sandboxed app द्वारा दी गई archive file को निर्दिष्ट स्थान पर extract करता है
  • extracted content पर quarantine extended attribute propagate नहीं होता, इसलिए बिना quarantine वाली file drop संभव थी

  • exploitation conditions और bypass

    • इस method का दुरुपयोग करने पर archive के भीतर की Mach-O files extraction के बाद execute permission खो देती हैं, इसलिए उन्हें तुरंत चलाया नहीं जा सकता
    • CVE-2021-30990 की technique की तरह symlink का उपयोग एक bypass हो सकता है
    • लेकिन यह XPC method केवल directories और regular files extract करता है, और archive से symlink extraction की अनुमति नहीं देता
    • एक bypass तरीका payload app को sandbox app container path में extract करना है
    • sandboxed app के पास उस path पर read/write permission होती है, इसलिए वह सीधे symlink बना सकती है या chmod से execute permission दे सकती है
    • दूसरा तरीका payload app को दो बार archive करना है
      • भेद्य XPC method से outer ZIP को extract करें
      • system open command से inner ZIP को extract करें

  • patch

    • Apple ने macOS Ventura 13.3 में patch किया ताकि incoming XPC clients के com.apple.TrialArchivingService.internal entitlement की जाँच की जाए
    • यदि यह entitlement न हो, तो XPC connection reject कर दिया जाता है

CVE-2023-32414: ArchiveService

  • भेद्य service /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/XPCServices/ArchiveService.xpc है
  • यह service Service Sandbox में चलती है, लेकिन dropped files पर quarantine लागू नहीं होता
  • यह service सभी XPC clients को allow करती है
  • unarchiveItemWithURLWrapper:… method sandboxed app द्वारा दिए गए item को निर्दिष्ट स्थान पर decompress करता है
  • extracted content पर quarantine extended attribute propagate नहीं होता, इसलिए sandboxed app बिना quarantine वाली मनमानी files drop कर सकती थी
  • XPC client DesktopServicesPriv.framework की Objective-C class DSArchiveService में पहले से implement था

  • patch

    • Apple ने macOS Ventura 13.4 में patch किया ताकि incoming XPC clients के com.apple.private.ArchiveService.XPC entitlement की जाँच की जाए
    • यदि यह entitlement न हो, तो XPC connection reject कर दिया जाता है

CVE-2023-32404: ShortcutsFileAccessHelper

  • भेद्य service /System/Library/PrivateFrameworks/WorkflowKit.framework/XPCServices/ShortcutsFileAccessHelper.xpc है
  • यह service sandbox restrictions के बिना चल सकती थी, इसलिए App Sandbox escape के लिए इसका दुरुपयोग संभव था
  • code signing में Full Disk Access के लिए विशेष TCC entitlement भी शामिल था
  • इसलिए इस भेद्यता का उपयोग TCC protection को पूरी तरह bypass करने के लिए भी किया जा सकता था
  • यह service सभी XPC clients को allow करती है
  • WFFileAccessHelperProtocol का एकमात्र method extendAccessToURL:completion: XPC client को मनमाने URL के लिए read/write permission देने के लिए design किया गया था
    • अंदरूनी रूप से यह file access token जारी करने के लिए sandbox_extension_issue_file API को call करता है
    • मनमाना URL sandboxed XPC client द्वारा निर्दिष्ट किया जाता है

  • patch

    • Apple ने macOS Ventura 13.4 में patch किया ताकि incoming XPC clients के com.apple.shortcuts.file-access-helper entitlement की जाँच की जाए
    • यदि यह entitlement न हो, तो XPC connection reject कर दिया जाता है

CVE-2023-41077: mscamerad-xpc और बार-बार किए गए patch bypass

  • भेद्य service /System/Library/Frameworks/ImageCaptureCore.framework/XPCServices/mscamerad-xpc.xpc है
  • यह service sandbox प्रतिबंधों के बिना चल सकती थी, इसलिए इसका दुरुपयोग App Sandbox से बाहर निकलने के लिए किया जा सकता था
  • code signing में ऐसे विशेष TCC entitlement थे जिनसे बिना user prompt के Photos और Removable Volumes तक पहुँचा जा सकता था
  • इसलिए इन TCC सुरक्षा उपायों को भी साथ में bypass किया जा सकता था

  • भेद्य flow

    • default service नाम com.apple.mscamerad-xpc है
    • service सभी XPC clients को अनुमति देती है
    • ICXPCDeviceManagerProtocol का openDevice:withReply: एक नया MSCameraDevice खोलता और configure करता है
    • नए device initialization के दौरान, camera device के लिए service routine देने हेतु एक और anonymous XPC service खोली जाती है
    • यह anonymous XPC service भी सभी XPC clients को अनुमति देती है
    • ICCameraDeviceProtocol का requestReadDataFromObjectHandle:options:withReply: method अनुरोधित file item की सामग्री पढ़कर XPC client को लौटाता है
    • अनुरोधित file path को XPC client नियंत्रित कर सकता था, इसलिए sandbox app container के बाहर की arbitrary files पढ़ सकती थी
    • service के शक्तिशाली TCC entitlement की वजह से user prompt के बिना user की Photos भी पढ़ी जा सकती थीं

  • नकली camera device configuration

    • MSCameraDevice DMG file बनाकर और mount करके emulation कर सकता था
    • DMG volume के अंदर file path यदि किसी विशेष regex से मेल खाता, तो file item को ICCameraFile के रूप में index किया जाता था
    • folder नाम के उदाहरण: 123abcde, DCIM, dcIm
    • file नाम के उदाहरण: abcd1234.mp3, 1234E5678.HEIC
    • sandbox app DMG file drop करके, उसे खोलकर और mount करके इस समस्या को trigger कर सकती थी
    • XPC client पहले से ImageCaptureCore framework में implement किया गया था

  • patch और bypass

    • Apple ने macOS Sonoma 14 में acceptConnection: में नई जाँच जोड़ी
    • अगर client के पास com.apple.private.imagecapturecore.authorization_bypass private entitlement हो तो उसे अनुमति दी जाती थी
    • या अगर client platform binary हो तो भी अनुमति दी जाती थी
    • platform binary वाली शर्त को bypass किया जा सकता था क्योंकि Apple-signed binary में dynamic library inject की जा सकती थी
      • entitlement के बिना Apple-signed binary /bin/ls चुना गया
      • DYLD_INSERT_LIBRARIES environment variable से पहले वाले exploit code वाली dylib inject की गई
      • इसके बाद पहले की तरह XPC service से संचार किया गया
    • Apple ने इस bypass report को CVE-2024-23253 दिया
    • macOS 14.4 में दूसरी शर्त को और कड़ा किया गया, ताकि XPC client सिर्फ platform binary ही न हो बल्कि CS_REQUIRE_LV या CS_FORCED_LV flags के साथ signed भी हो
    • इस patch को भी bypass किया जा सकता था
      • /bin/ls में dylib inject की गई
      • runtime पर csops API से आवश्यक flags manually set किए गए
      • इसके बाद XPC service की जाँच पार कर ली गई
    • Apple ने इस दूसरे bypass को CVE-2024-40831 दिया
    • macOS Sequoia 15 में फिर patch करके केवल उन्हीं XPC clients को अनुमति दी गई जिनके पास com.apple.private.imagecapturecore.authorization_bypass private entitlement है

CVE-2023-42961: intents_helper

  • इस भेद्यता का दुरुपयोग iOS पर भी किया जा सकता है
  • भेद्य service /System/Library/Frameworks/Intents.framework/XPCServices/intents_helper.xpc है
  • service sandbox प्रतिबंधों के बिना चल सकती है और सभी XPC clients को अनुमति देती है
  • filePathForImageWithFileName function में path traversal की वजह से arbitrary path access संभव था
  • fileName parameter XPC client द्वारा नियंत्रित किया जा सकने वाला arbitrary string है

  • प्रभावित methods

    • भेद्य function तक दो XPC methods से पहुँचा जा सकता था
    • retrieveImageWithIdentifier:completion: का दुरुपयोग .png extension वाली arbitrary file पढ़ने के लिए किया जा सकता था
    • पढ़ा गया data INImage instance के member variable में store होकर XPC client को लौटाया जाता था
    • purgeImageWithIdentifier:completion: का दुरुपयोग arbitrary file path delete करने के लिए किया जा सकता था

  • patch

    • Apple ने macOS Sonoma 14.0 में XPC client input string को normalize करने वाला patch जारी किया
    • path traversal में इस्तेमाल होने वाले special characters को काट दिया गया

CVE-2024-27864: diskimagescontroller

  • CVE entry लेखन के समय public disclosure की प्रतीक्षा में थी
  • भेद्य service /System/Library/PrivateFrameworks/DiskImages2.framework/XPCServices/diskimagescontroller.xpc है
  • इस service के code signing में com.apple.diskimages.creator-uc entitlement था, जिससे यह शक्तिशाली operations कर सकती थी
  • इस entitlement की दो मुख्य भूमिकाएँ हैं
    • यह FDA entitlement वाले /usr/libexec/diskimagesiod से संचार करता है, जो वास्तविक attach operation करता है
    • यह IOKit service AppleDiskImagesController से connect होकर DMG files के लिए device बनाता है और quarantine लागू करता है

  • भेद्यता का कारण

    • service सभी XPC clients को अनुमति देती है
    • DIControllerProtocol का attachWithParams:reply: method attack surface था
    • अंदर से यह checkAttachEntitlementWithError को call करता है, लेकिन नाम के विपरीत यह function हमेशा TRUE लौटाता है
    • DiskImages2.framework में Objective-C class DIAttachParams के रूप में XPC client पहले से implement किया गया है
    • framework का client code जाँचता है कि input URL quarantine स्थिति में है या नहीं
    • अगर input URL quarantine स्थिति में हो, तो attach से पहले quarantine parameter set किया जाता है, और यह parameter XPC service को target device पर quarantine लागू करने के लिए कहता है
    • अपना XPC client बनाने पर quarantine parameter set करना छोड़ा जा सकता है और attachWithParams:reply: को सीधे call किया जा सकता है
    • परिणामस्वरूप, quarantined DMG file attach करते समय संबंधित device पर quarantine लागू नहीं किया जा सकता था

  • patch

    • Apple ने macOS Sonoma 14.4 में validation logic को client side से server side पर move किया
    • यदि input file path quarantine स्थिति में हो, तो server संबंधित device पर सीधे quarantine लागू करता है

CVE-2023-42977: PerfPowerServicesSignpostReader

  • भेद्य service /System/Library/PrivateFrameworks/PowerlogCore.framework/XPCServices/PerfPowerServicesSignpostReader.xpc है
  • यह service sandbox प्रतिबंधों के बिना चल सकती थी और सभी XPC clients को अनुमति देती थी
  • XPCSignpostReaderProtocol में 6 methods हैं, लेकिन Apple ने केवल submitSignpostDataWithConfig:withReply: को implement किया था और बाकी 5 empty implementations थे
  • इस method का मुख्य logic log data इकट्ठा करके उसे gzip file के रूप में archive करना है
  • XPC client द्वारा नियंत्रित tagUUID string से powerlog path को मनचाहे path पर hijack किया जा सकता था

  • मनचाहे path को delete करना

    • function के भीतर archiveDirectoryAt:deleteOriginal: को call करके powerlog path delete किया जाता है
    • TagUUID में path traversal string डालने पर मनचाहे path deletion primitive मिल सकता है

  • मनचाही directory बनाना और पूर्ण sandbox escape

    • createSignpostFile: function powerlog path पर directory बनाता है
    • इससे quarantine extended attribute के बिना मनचाही directory बनाई जा सकती है
    • quarantine के बिना मनचाही directory creation primitive पूर्ण sandbox escape तक ले जा सकता है
    • लेख में CVE-2023-32364 की तकनीक का उपयोग किया गया है
      • quarantine के बिना .app folder बनाया जाता है
      • Contents/MacOS के नीचे /bin/bash symlink बनाया जाता है
      • LSEnvironment में BASH_ENV set किया जाता है
      • open ./poc.app से execute किया जाता है

  • patch

    • Apple ने macOS Sonoma 14.0 में XPC client की UUID string को normalize करने के लिए patch किया
    • input string valid UUID न होने पर function तुरंत return कर देता है

दोहराया जाने वाला पैटर्न

  • मुख्य attack surface System या User domain की XPC services नहीं, बल्कि system और private frameworks के भीतर की PID domain XPC services हैं
  • जिन XPC services का Service Type Application है, वे सिर्फ framework load होने से sandboxed app के PID domain में register हो सकती हैं
  • कई भेद्य services ने sandboxed client calls की अपेक्षा नहीं की, इसलिए वे ये checks छोड़ बैठीं
    • XPC client entitlement check
    • sandboxed client है या नहीं, इसकी जाँच
    • input path normalization
    • server-side quarantine state verification
  • बार-बार exploit की गई शर्तें इस प्रकार थीं
    • quarantine के बिना file·folder drop पूर्ण sandbox escape तक ले जा सकता है
    • unzip के दौरान quarantine extended attribute हट जाने पर Gatekeeper bypass और sandbox escape हो सकता है
    • Service Sandbox द्वारा बनाई गई files पर default रूप से quarantine लागू नहीं होता
  • अभी भी patch की प्रतीक्षा में 5 reports बाकी हैं

App Sandbox और Service Sandbox पर अतिरिक्त टिप्पणियाँ

  • Apple ने एक report के बारे में कहा कि नया execute हुआ application वर्तमान process context में नहीं होता और वह वर्तमान process के entitlement या privileges share नहीं कर सकता, इसलिए यह expected behavior है
  • App Sandbox में drop की गई files पर default रूप से quarantine लागू होता है
  • Service Sandbox में drop की गई files पर default रूप से quarantine लागू नहीं होता
  • यह तथ्य अपने आप में flaw नहीं माना गया कि नया execute हुआ process वर्तमान service execution context में नहीं होता, इसलिए वह उस service के entitlement या privilege share नहीं करता
  • इसके विपरीत, यदि attacker sandbox-restricted service context में RCE हासिल करने के बाद नया non-sandbox app drop और execute करके target service के sandbox प्रतिबंधों से बाहर निकल सकता है, तो इसे flaw माना जा सकता है
    • उदाहरण के तौर पर NSO Group के 0-click exploit target IMTranscoderAgent का उल्लेख किया गया है
  • com.apple.WebDriver.HTTPService.xpc उस उदाहरण के रूप में आता है जो WBSEnableSandboxStyleFileQuarantine API को manually call करता है
  • निष्कर्ष यह है कि App Sandbox से Service Sandbox में escape करना macOS पर व्यवहारिक रूप से Non Sandbox में जाने जैसा है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-11-09
Hacker News की राय

  • यहाँ XPC services को एक-एक करके अलग से patch करना थोड़ा अजीब लगता है
    यह sandbox के अपने design की समस्या जैसा दिखता है, और सवाल है कि apps के अंदर इस्तेमाल के लिए दिखने वाली इतनी सारी XPC services sandboxed apps से accessible क्यों हैं

    • सही. macOS में इसे बाद में जोड़ते समय, UNIX और NeXTSTEP से आई चीज़ों को न तोड़ने के लिए यह संभवतः एक समझौता रहा होगा
      Windows में भी WinRT sandbox, Win32 app sandbox, secure kernel, driver protection जैसे मिलते-जुलते कई mechanism हैं, लेकिन अलग-अलग configurations में एक ही executable चलाना हो तो backward compatibility की खामियाँ रह जाती हैं
      Mobile operating systems के लिए यह काफ़ी आसान है, क्योंकि उनमें backward compatibility नहीं होती और execution model को बहुत सख़्ती से limit किया जा सकता है

  • MacOS को किसी विशाल blocklist के ढेर जैसी approach के बजाय, capability-based Darwin containers जैसी चीज़ की ज़रूरत है

    • https://github.com/darwin-containers
      https://news.ycombinator.com/item?id=37655477
      Desktop पर अच्छी तरह काम करने वाला कोई security model नहीं है
      दूसरे comment की तरह, iOS पुराने baggage से मुक्त था, इसलिए वह एक ऐसा security model दे पाया जो समझ में आता है
      वहीं अगर Telegram contacts और photos की पूरी sharing माँगे, तो लोग सच में allow कर देते हैं

  • अच्छा काम है
    लेकिन शक है कि ऐसी architecture सही दिशा है या नहीं. किसी attack को रोकने के लिए जब भी security framework बनाया जाता है, लगता है पूरी तरह नई तरह की problems निकल आती हैं, और अंत में यह महसूस नहीं होता कि चीज़ें ज़्यादा safe हुई हैं
    यह Dutch tax law जैसा है, जहाँ misuse रोकने के लिए patches लगातार जमा होते गए हैं, और शायद अब वह चेतना भी प्राप्त कर चुका हो

    • ऐसी कई systems की वजह यह है कि उन्हें शुरू से अंत तक सही मायने में secure design नहीं किया गया था
      सही तरीका अक्सर backward compatibility या developers द्वारा features adopt करने से इनकार के कारण market में fail हो जाता है. WinRT sandbox इसका example है
      Phone security आसान थी, क्योंकि backward compatibility की चिंता नहीं थी, और अब तक App Store gatekeeping की वजह से जो developers participate करना चाहते थे, उन्हें मानना ही पड़ता था
    • आखिरकार security और backward compatibility साथ निभाना मुश्किल है
      आज चल रहे सभी operating systems को अगले century तक secure रखना है तो उन्हें शून्य से फिर बनाना होगा, और इस process में बहुत सारा code फेंकना होगा. यही चुकानी पड़ने वाली कीमत है
    • Dutch tax law का ज़िक्र मज़ेदार है. उन “misuse loopholes” में से कुछ जानबूझकर डाले गए हों तो भी शायद बहुत विवादास्पद नहीं लगेगा
      अंदाज़ा लगाया जा सकता है कि consumer computing में भी ज़्यादा vulnerabilities डालने की कोशिश करने वाली मजबूत शक्तियाँ हो सकती हैं
      इनके मशहूर examples ये हैं
      https://en.wikipedia.org/wiki/Dutch_Sandwich
      https://en.wikipedia.org/wiki/Intel_Management_Engine#Assert...

  • MacOS, यानी NeXTstep, शुरुआत से ही एक open और बेहद extensible operating system के तौर पर बनाया गया था
    Third-party extensions या hooks जोड़ने के अनगिनत तरीके थे, और कई runtimes से software तक access किया जा सकता था, इसलिए उस समय यह सब smoothly साथ काम करता था—यह अपने-आप में एक impressive technical achievement था
    Java, classic Mac, X11, और NeXTstep codebase kernel के कई extension entry points की वजह से बिना समस्या साथ-साथ चलते थे
    इसके अलावा platform में ऐसे APIs भी थे जो apps को आपस में आसानी से communicate करने देते थे
    लेकिन Apple धीरे-धीरे उस philosophy से पीछे हटता गया, और system को लगातार बंद करता जा रहा है. यह काफ़ी दिलचस्प सफ़र है

  • SBPL(sandbox profile language) दिलचस्प है. Details यहाँ हैं: https://github.com/0xbf00/simbple
    सोच रहा हूँ कि macOS के अंदर इसे handle करने वाला कोई Scheme interpreter कहीं मौजूद है या नहीं
    PS: लगता है यह काम sandbox-exec करता है. संदर्भ: https://reverse.put.as/wp-content/uploads/2011/09/Apple-Sand...

  • प्रभावशाली खोज है. लेख में भी संकेत है कि इसी तरह की कमियाँ अभी भी बाहर मौजूद होने की संभावना बहुत अधिक लगती है
    अगर Apple ऐसी services को harden करने की approach को redesign नहीं करता, तो XPC-related CVEs लगातार आते रहेंगे

  • sandbox मुझे पसंद भी है और नापसंद भी
    यह शानदार second line of defense है, लेकिन बड़े organizations sandbox से बाहर निकले बिना meaningful काम न कर पाने वाली remote code execution vulnerabilities को fix करने से इनकार करने की तरफ झुकते हैं. इसलिए sandbox को main defense की तरह इस्तेमाल किया जाने लगता है, और यही दुखद है

    • “अगर sandbox से बाहर नहीं निकल सकते तो remote code execution vulnerability fix करने से इनकार करते हैं” — यह किसके बारे में है, समझ नहीं आया
      मेरी जानकारी में Apple, Microsoft, Google—तीनों के पास bug bounty programs हैं, और sandbox escapes पर बड़ा reward देते हैं, लेकिन sandbox में रुक जाने वाली vulnerabilities पर भी reward देते हैं
      सभी अच्छी तरह जानते हैं कि attackers ऐसी remote code execution vulnerabilities जमा रखते हैं जो फिलहाल usable नहीं हैं, और sandbox escape मिलने पर उन्हें साथ में इस्तेमाल करते हैं

  • विषय से थोड़ा हटकर, लेकिन अगर sandbox विशेषज्ञों में से किसी को maximum "pattern serialization length" सीमा को bypass करने की कोई रणनीति पता हो, तो इस issue ने मुझे काफ़ी समय तक परेशान किया है: https://github.com/NixOS/nix/issues/4119
    दुर्भाग्य से sandbox-exec की documentation लगभग नहीं के बराबर है, और इसे deprecated किए जाने की बातें भी हैं, इसलिए इसे हल करना काफ़ी सिरदर्द है

  • macOS में bypasses का सिलसिला कभी खत्म नहीं होता। वजह यह है कि यह operating system मूल रूप से ऐसे granular permissions के लिए कभी design ही नहीं किया गया था
    इसे legacy Mac OS और NeXTSTEP technologies के ऊपर बाद में यूं ही नहीं चढ़ाया जा सकता
    मैं security researcher भी नहीं, बस पुराने apps का developer हूं, फिर भी मैंने खुद कई bypasses खोजे हैं। कहें तो मुझे पता है कि लाशें कहां दबी हैं
    लेकिन आखिरकार मैंने ढूंढना छोड़ दिया। Apple का security vulnerability reporting system पूरी तरह गड़बड़ है, और ऐसा लगा कि उनकी दिलचस्पी बस जितना हो सके उतने लंबे समय तक मुंह बंद रखवाने में है। समय की बर्बादी है
    कुल मिलाकर macOS security theater का शिकार लगता है। कमजोर किए गए software और अंतहीन permission requests से users और legitimate developers दोनों को नुकसान होता है, जबकि असली attackers चाहें तो आसानी से bypass कर सकते हैं। यह Apple की पुरानी Windows Vista parody जैसा है

    • लगता है इस लेख के researcher ने काफ़ी सारे holes को credit के साथ patch करवाने में सफलता पाई। हालांकि इन CVEs में से कुछ कई साल पुराने लगते हैं
      कंपनी अपने bugs ठीक करने के लिए ज्यादा से ज्यादा समय चाहती है, यह खेल का हिस्सा भी है। क्या वे सच में चाहेंगे कि दूसरी कंपनियां मिली हुई vulnerabilities को जितनी जल्दी हो सके public कर दें? users कितनी जल्दी upgrade करेंगे, इस पर आपका control नहीं होता, इसलिए disclosure में देरी करना end users के लिए हमेशा बेहतर होता है और researcher की publicity की इच्छा से ऊपर होना चाहिए
      Apple sandbox architecture आम तौर पर काफ़ी अच्छी तरह design किया हुआ लगता है। इस मामले में architecture या communication में कहीं समस्या हुई लगती है
      bypasses मौजूद होने की एक वजह यह भी है कि desktop operating systems से बहुत ज्यादा features की मांग की जाती है। desktop operating systems को server platforms की तुलना में कहीं ज्यादा sophisticated और complex operating systems माना जा सकता है। web browsers में इतने CVEs होने की वजह भी यही है। हमें security भी चाहिए और features भी, इसलिए दोनों के टकराने वाला कोई middle ground अनिवार्य रूप से बनता है
    • “इसे legacy Mac OS और NeXTSTEP technologies के ऊपर बाद में यूं ही नहीं चढ़ाया जा सकता” वाली बात के उलट, Apple पूरी stack का owner है, इसलिए वह ऐसा कर सकता है और वास्तव में करता आया है
      पिछले 20 वर्षों में macOS software और hardware को धीरे-धीरे harden किया जाना इसका सबूत है
      यह इतना gradual था कि ज्यादातर end users ने ध्यान भी नहीं दिया, लेकिन macOS developers major updates और minor updates दोनों में झेलने पड़ने वाले security-related issues को बहुत अच्छी तरह जानते हैं। उदाहरण के लिए:
      https://eclecticlight.co/2024/08/…
      https://eclecticlight.co/2024/08/…
      https://eclecticlight.co/2024/08/…
      https://eclecticlight.co/2024/09/…
    • ऐसा legacy burden लगता है कि सभी mainstream operating systems में है
      capability-based systems हैं, लेकिन वास्तव में व्यापक रूप से इस्तेमाल होने वाला कोई नहीं है
      समाधान क्या है, यह ठीक से नहीं पता। फिर भी security को ऊपर से जोड़ने की कोशिश कुछ न करने से बेहतर लगती है, जहां किसी application vulnerability का मतलब तुरंत पूरे user account पर कब्जा हो जाना हो
    • अगर “legacy Mac OS के ऊपर बाद में जोड़ा नहीं जा सकता”, तो SELinux ने यह कर दिखाया—फिर MacOS को मूल रूप से रोकने वाली चीज क्या है?
    • इन restrictions की वजह यह है कि third-party developers के लिए Apple products से compete करना मुश्किल बनाया जाए

  • pid domain में छूट गई XPC services macOS sandbox restrictions को bypass करने का smart तरीका हैं
    permission checks से बचने वाली dyld injection trick भी साफ-सुथरी है
    Apple के patches यहां अस्थायी उपाय जैसे लगते हैं, और शायद sandbox inheritance के काम करने के तरीके को ठीक से दुरुस्त करना पड़े