macOS के permission pop-up पर भरोसा किया जा सकता है?

• CVE-2025-31250 macOS के TCC permission consent pop-up को भरोसेमंद बनाना मुश्किल करने वाली vulnerability है, जिसमें स्क्रीन पर दिखने वाला app और असल में permission पाने वाला app अलग हो सकते थे
• समस्या tccd के TCCAccessRequestIndirect handling में थी, और target_path pop-up में दिखाए जाने वाले app name के लिए, जबकि target_identifier असल में permission पाने वाले app identifier के लिए इस्तेमाल होता था
• पहले के bypass की तरह fake app, Dock shortcut या user click誘導 की जरूरत नहीं थी; अगर user spoofed pop-up में Allow दबा दे, तो attack सफल हो सकता था
• Apple ने इसे macOS Sequoia 15.5 में patch किया, लेकिन उसी दिन आए Ventura 13.7.6 और Sonoma 14.7.6 को patch नहीं किया, और पुष्टि की कि पुराने versions के लिए patch की कोई योजना नहीं है
• attacker FaceTime, Voice Memos, System Settings जैसे apps खुलने के क्षण को निशाना बनाकर permission pop-up spoofing कर सकता है, जिससे user असल permission target को गलत समझ सकता है

---

CVE-2025-31250 का मुख्य व्यवहार

• CVE-2025-31250 macOS TCC permission pop-up में दिखने वाले app और असल में permission पाने वाले app को अलग करने की अनुमति देने वाली vulnerability थी
• patch से पहले निम्न configuration संभव था
  • Application A macOS से permission consent pop-up दिखाने का अनुरोध करता है
  • pop-up ऐसा दिखता है जैसे वह Application B से आया हो
  • user की consent का result Application C पर लागू होता है
• तीनों apps अलग-अलग हो सकते थे, जबकि सामान्य उपयोग में इनके आम तौर पर एक ही app होने की संभावना अधिक होती है
• मुख्य समस्या यह थी कि pop-up में दिखने वाला app और वास्तविक permission प्राप्त करने वाला app अलग होने पर भी validation पर्याप्त नहीं था

patch लागू होने का दायरा और correction

• शुरुआती説明 के विपरीत, patch केवल macOS Sequoia 15.5 पर लागू हुआ
• उसी दिन release हुए macOS Ventura 13.7.6 और macOS Sonoma 14.7.6 patch नहीं हुए
• Sonoma 14.7.6 virtual machine में PoC compile करके चलाने पर vulnerability अब भी काम करती है
• Apple Product Security ने report status को “We’ve addressed the issue in all planned releases.” में बदला, और बाद में पुष्टि की कि Ventura और Sonoma के लिए इस vulnerability का patch plan नहीं है
• नतीजतन Ventura और Sonoma इस vulnerability के प्रति vulnerable बने हुए हैं

जहां TCC और Apple Events मिलते हैं

• TCC Apple operating systems का core permission system है, और internally tccd daemon तथा private TCC framework के जरिए चलता है
• developers private API को सीधे call नहीं करते, लेकिन public API जरूरत पड़ने पर internally TCC functionality को call करती है
• tccd Apple की XPC API का उपयोग करके messages प्राप्त करता है
• patch से पहले, tccd को XPC message भेज सकने वाला app crafted message भेजकर permission pop-up display app और वास्तविक permission receiving app को अलग कर सकता था

Apple Events और TCC data model

• Apple Events macOS की inter-process communication mechanism है, और आजकल मुख्य रूप से automation के लिए उपयोग होती है
• Apple Events automation को Apple की Open Scripting Architecture के जरिए script किया जा सकता है
  • प्रमुख language AppleScript है
  • JavaScript भी इस्तेमाल की जा सकती है
• macOS Mojave 10.14 से, किसी app को Apple Events भेजने के लिए TCC के जरिए user consent चाहिए
• TCC की user consent result user home folder के नीचे Application Support/com.apple.TCC/TCC.db SQLite database में save होती है
• सामान्य TCC row में requesting app, requested service, और user consent result होता है
• Apple Events को receiving app के आधार पर permission restrict करनी होती है, इसलिए यह indirect object column का उपयोग करता है
  • इस column में Apple Events प्राप्त करने वाले app का identifier होता है
  • Apple Events के अलावा FileProviderDomain service भी इस column का उपयोग करती है

vulnerable XPC message structure

• समस्या TCCAccessRequestIndirect function के logic bug में थी
• यह function TCC.db के indirect object column का उपयोग करने वाली access requests को handle करता है
• PoC का core यह तरीका है कि जब target_prompt 2 हो, तो दो fields को अलग-अलग भर दिया जाता है
  • target_path: GUI permission pop-up में दिखाने वाले app name को प्राप्त करने के लिए इस्तेमाल होता है
  • target_identifier: असल में database में record होकर permission पाने वाले app के bundle ID के रूप में इस्तेमाल होता है
• TCCAccessRequestIndirect indirect object के लिए function होने के बावजूद, empty string को indirect object के रूप में देकर कई ऐसे TCC services के साथ भी इस्तेमाल किया जा सकता था जो उस column का उपयोग नहीं करते
• यह bug अन्य access request functions में मौजूद नहीं था

exploitation conditions और limitations

• vulnerability का exploitation तभी सफल होता है जब user permission pop-up में Allow दबाए
• इस्तेमाल की जा सकने वाली TCC services सीमित थीं, लेकिन Microphone और Camera जैसी प्रमुख services शामिल थीं
• specific directory access permission pop-up भी spoof किए जा सकते थे, लेकिन files के आसपास के अतिरिक्त security layers के कारण usefulness कम थी
• malicious app यह भी कर सकता था कि permission खुद पर नहीं बल्कि किसी दूसरे app पर लागू हो
  • यह उस path में उपयोगी हो सकता है जहां attacker किसी दूसरे app को control कर सकता है, लेकिन उस app को TCC permission चाहिए

pop-up timing का इस्तेमाल करके धोखा

• अगर random permission pop-up दिखे, तो user के शक करने और Don’t Allow दबाने की संभावना होती है
• macOS apps running applications की list और current frontmost app देख सकते हैं
  • running apps देखना: NSWorkspace runningApplications
  • frontmost app देखना: NSWorkspace frontmostApplication
• malicious app किसी specific app के launch होने या frontmost app बनने तक wait कर सकता है, फिर उसी app name से spoofed permission pop-up दिखा सकता है
• उदाहरण के लिए FaceTime launch होने पर Camera permission pop-up, और Voice Memos launch होने पर Microphone permission pop-up spoof किया जा सकता है
• user app खोलने या switch करने के तुरंत बाद आए pop-up को उसी app की normal permission request समझ सकता है

पुराने TCC bypass paths से संबंध

• पहले tccd user home folder को HOME environment variable से determine करता था, जिससे fake home folder और fake TCC.db plant करके TCC bypass संभव था
• यह issue July 2020 के मध्य के update में patch हुआ, और उसके बाद tccd operating system की user information directory से home folder lookup करता है
• इसके बाद भी user home folder change का abuse करने वाले bypass cases रहे
  • Wojciech Reguła ने macOS के GUI user information directory editor plugin system का abuse करने वाला CVE-2020-27937 disclose किया
  • Microsoft Threat Intelligence team ने import/export commands का उपयोग करने वाला powerdir bypass disclose किया
• user home folder बदलने के लिए आम तौर पर दो चीजें चाहिए
  • root privileges
  • किसी specific TCC service के लिए user consent
• CVE-2025-31250 root privilege requirement को bypass नहीं कर सकता, लेकिन required TCC consent को spoofed pop-up से दिलवा सकता है
• अगर malicious app user को धोखा देकर consent ले ले और root privilege escalation भी हासिल कर ले, तो user information directory बदलकर fake TCC.db plant करने का path संभव है
• REG.db valid TCC.db को track करता है, लेकिन TCC में ऐसा function है जिससे app REG.db में entry add कर सकता है, इसलिए planted TCC.db path add किया जा सकता है

users को दिखने वाली permission management की सीमाएं

• TCC System Settings के Privacy & Security panel के पीछे चलने वाला system है
• Apple Events से संबंधित consent results Automation section में दिखते हैं
• Privacy & Security panel में user अपने दिए हुए consents देख सकता है, और कई मामलों में specific consent revoke कर सकता है
• लेकिन अगर attacker user को धोखा देकर Apple Events permission allow करवाता है, तो वह consent result System Settings में दिखाई नहीं देता था
• user tccutil CLI tool से consent revoke कर सकता है, लेकिन इस tool की documentation limited है और अधिकांश users के लिए इसके बारे में जानना मुश्किल है
  • Apple documentation के रूप में पुराना Technical Q&A और IT training page मौजूद हैं

Endpoint Security और detection की संभावना

• Apple का Endpoint Security framework हाल में TCC database modification monitoring support करना शुरू कर चुका है
• Objective-See की post इस बदलाव को cover करती है: Endpoint Security TCC database monitoring
• अगर यह feature उम्मीद के मुताबिक काम करे, तो framework इस्तेमाल करने वाले apps user को बाद में notify कर सकते हैं कि असल में किस app को permission दी गई
• हालांकि यह detection संभावना केवल उस छोटी अवधि में सीधे मायने रखती थी, जब Apple ने Endpoint Security event add किया था और vulnerability patch के बीच का समय था

Apple की fix approach

• macOS Sequoia 15.5 के tccd binary analysis के परिणामस्वरूप, final patch शुरुआती अनुमान से अधिक complex था
• patch के बाद उसी तरीके से TCC pop-up spoof नहीं किया जा सकता
• indirect object में empty string डालकर अन्य TCC services के लिए TCCAccessRequestIndirect इस्तेमाल करने वाला behavior भी restricted लगता है
• vulnerable form वाले messages अब tccd में silently drop होकर कोई action नहीं करते, ऐसा observe हुआ
• simple verification में यह अच्छा patch लगा, लेकिन पूरा behavior पूरी तरह समझने के लिए additional analysis जरूरी है

reporting और patch तक का flow

• यह vulnerability Apple को report किया गया दूसरा bug था, और Apple द्वारा patch किए गए reports में patch आने तक सबसे अधिक समय लेने वाला मामला था
• reporting process में initial report, Apple Product Security की additional explanation request, potential full TCC bypass path sharing, PoC test updates, reproduction status confirmation, और कई बार progress inquiries शामिल थीं
• suggested simple patch यह था कि दोनों fields एक ही app की ओर point करते हैं या नहीं, इसे validate किया जाए
• Apple ने कई बार जवाब दिया कि investigation चल रही है, और बाद में credit name मांगा, फिर patch release किया
• vulnerability का नाम “TCC, Who?” रखा गया