Siriously Leaky: Exploring Overlooked Attack Surfaces in Apple's Ecosystem

Siri-ously Leaky: Exploring Overlooked Attack Surfaces Across Apple's Ecosystem

Speaker: Richard Im

Conference: DEF CON 33

YouTube: https://www.youtube.com/watch?v=MWvpOW-PRJI

Slides: https://media.defcon.org/DEF%20CON%2033/DEF%20CON%2033%20presentations/Richard%20Im%20-%20Siri-ously%20Leaky%20Exploring%20Overlooked%20Attack%20Surfaces%20Across%20Apple%27s%20Ecosystem.pdf

Overview

Apple's iOS security model rests on a layered architecture combining hardware-backed authentication, process isolation via XPC, and tightly scoped permission frameworks. The implicit promise to users is that features like Face ID-protected Hidden Albums, Focus Mode filters, and Lockdown Mode represent reliable privacy boundaries. Richard Im's DEF CON 33 presentation systematically dismantles that promise across multiple attack surfaces, demonstrating that the coordination layer between iOS subsystems — particularly Siri, the Photos framework, and companion AI integrations — introduces information disclosure vulnerabilities that bypass user-visible authentication prompts entirely.

Im's talk is notable for both its breadth and its specificity: he traced each vulnerability to a concrete IPC (inter-process communication) design decision and showed working proof-of-concept exploits on shipping iOS builds. The talk was delivered as a first-time DEF CON speaker and has since been cited in discussions around iOS's increasingly complex AI-integration surface area.

Background

▶ Watch: Introduction to overlooked Apple ecosystem attack surfaces in Siri and Shortcuts (6:25)

Apple's Privacy Architecture: The Intended Model

iOS's security model is built on several interlocking components:

• Secure Enclave: A dedicated co-processor handling cryptographic key material for biometric authentication. It issues a yes/no verdict for Face ID/Touch ID without exposing the underlying key.
• LocalAuthentication framework: The standard API surface through which apps request biometric authentication. Most first-party and third-party apps use this framework to gate sensitive content behind Face ID.
• XPC (Cross-Process Communication): iOS's primary mechanism for sandboxed inter-process messaging. XPC services run as separate processes with their own sandboxes, accepting structured requests through "mail slots" and returning responses — enabling both performance optimization and privilege separation.
• biometrickitd: A background daemon acting as a biometrics broker. It mediates between the Secure Enclave result and the LocalAuthentication framework, handing off authentication state to requesting applications.

The Hidden Album feature introduced in iOS 16 and enhanced in iOS 18 is designed to store sensitive photos behind Face ID authentication. Users unlock the album to view contents; when they leave, the UI re-locks. The user-visible experience creates a strong expectation of privacy: the photos are inaccessible unless the device owner deliberately unlocks them.

Siri's Architecture

Siri's execution model involves several components operating at different privilege levels:

• SpringBoard: iOS's home screen process. It monitors the system for "Hey Siri" activations and bootstraps the Siri subsystem.
• assistantd: Siri's backend daemon. It parses spoken or typed input, maps it to structured intents, and dispatches requests to appropriate system APIs or third-party app integrations.
• Siri UI (blue bubbles): The front-end rendering layer, entirely separate from assistantd's logic.
• Apple Intents framework: A structured vocabulary of actions — expressed as typed data rather than free-form strings — that allows Siri to request contextual information from apps via official system APIs rather than screen-scraping.

This architecture was designed for correctness and security. Siri is supposed to ask apps through the proper API channels what content is "in context," not access raw memory or bypass authentication. The vulnerability Im found shows that this design, while architecturally sound, fails at the intersection of content caching and context API semantics.

Key Findings

▶ Watch: I found in uh shortcuts that Okay, let's just see what happens here. (27:20)

Im identified multiple distinct vulnerabilities across Apple's ecosystem, all sharing a common theme: authentication gates the UI layer, but not the underlying data layer accessible to privileged daemons.

1. Hidden Album Bypass via Siri + Photos Context API

The central exploit chain:

1. The user opens the Hidden Album and authenticates with Face ID.
2. The Photos app decrypts the album and renders the content. As an optimization, photosimageconversionservice — an XPC service responsible for generating resized thumbnails and screen-resolution variants — processes and caches image assets in memory.
3. The user exits the Hidden Album. The Photos UI re-locks (requiring Face ID to re-open).
4. The user invokes Siri and asks a question about the currently visible (or recently viewed) photo.
5. Siri, via assistantd, calls the Photos system API to request contextual information about what photo is "currently in context."
6. The Photos system API does not check whether the Hidden Album UI is currently locked. It returns the metadata and asset reference for the last-viewed photo — which is still warm in memory through the image conversion service.
7. Siri can then describe the photo, pass it to ChatGPT for analysis, or use Apple's on-device image understanding — all without re-prompting for Face ID.

The fault line, in Im's words, is that "the request doesn't go to the locked Photos UI." The lock state is a property of the UI view controller, not of the underlying data context that the system API returns. photosimageconversionservice retains its cached variants for a performance window after the album is closed, and assistantd has the privilege to retrieve that context through the intent system.

2. Siri Bypass Without AI Features

Im demonstrated that the vulnerability is not contingent on ChatGPT integration. Even with all AI features disabled, invoking Siri after viewing a Hidden Album photo causes Siri to verbally describe or acknowledge the photo's existence — demonstrating that the context leak occurs at the intent/API layer regardless of downstream AI processing.

3. Additional Attack Surfaces

Im's talk extended beyond the Hidden Album to explore other locations in Apple's ecosystem where similar trust boundary mismatches exist, including:

• Focus Mode filter bypasses: Examining whether notification and communication filters applied during Focus Mode are correctly enforced across all inter-process paths.
• Lockdown Mode surface area: Identifying areas where the elevated restrictions of Lockdown Mode do not propagate uniformly to all relevant daemons and XPC services.
• Companion device sync: Exploring whether authentication state is correctly synchronized (or constrained) when data is accessed via secondary devices linked through Apple's ecosystem.

Technical Deep Dive

▶ Watch: I showed you earlier where you can ask chat like, "Hey, like what do we talk ... (28:53)

The XPC Caching Window

The core mechanism enabling the Hidden Album leak is temporal: photosimageconversionservice is a long-lived XPC daemon that pre-generates multiple resolutions of recently viewed images for smooth UI performance. When the Hidden Album is unlocked and viewed, this service generates and retains:

• Thumbnail variants (low-resolution index images)
• Screen-resolution display variants
• Metadata structures (PHAsset objects containing unique identifiers, timestamps, and other properties)

These cached entries are not destroyed when the Hidden Album re-locks. From a performance standpoint, this is intentional and reasonable — constantly regenerating image variants would degrade the user experience. The problem is that assistantd, operating at a different privilege level, can request contextual photo information through a system API that returns this warm-cached data without consulting the lock state of the Photos Hidden Album UI.

Intent System Architecture

The Apple Intents framework maps natural-language inputs to structured, typed data objects. When Siri processes "describe the photo I was just looking at," it generates an intent such as INAnalyzeImageIntent or an equivalent contextual photo-retrieval intent. This is dispatched to the Photos system API through a privileged IPC channel.

The Photos API, when responding to this intent query, determines "what photo is in context" based on recently accessed assets — not based on the UI authentication state of the Hidden Album. This creates a semantic gap: the API is designed to return contextually relevant content for Siri to act on, but it does not have visibility into whether the originating UI view (the Hidden Album) is currently in a locked or unlocked state.

Privilege and Sandbox Boundaries

assistantd runs with elevated system privileges sufficient to communicate with the Photos framework's intent-handling service. The Photos intent endpoint is not sandboxed against Siri interactions — this is by design, since Siri is supposed to be able to perform actions like searching photos or adding items to reminders. The vulnerability exploits this legitimately broad privilege grant.

Demo / Proof of Concept

▶ Watch: Microsoft does things you know in a Microsoft way Microsoftish way. (34:43)

Im demonstrated the exploit live on stage:

1. Setup: iPhone running iOS 18 with a Hidden Album containing a sensitive photo. Face ID lock enabled by default.
2. Step 1: Open Photos → Hidden Album → authenticate with Face ID → view the sensitive photo.
3. Step 2: Exit the Hidden Album. The UI shows a locked state requiring Face ID to re-enter.
4. Step 3: Invoke Siri. Ask: "Hey Siri, what's in this photo?" or "Hey Siri, ask ChatGPT about the photo I was just looking at."
5. Result (with ChatGPT integration): Siri routes the photo asset to ChatGPT, which describes the image in detail — without any Face ID prompt.
6. Result (without ChatGPT): Siri verbally acknowledges and describes the photo using on-device image understanding, again without re-authentication.

The demo was repeatable across the presentation and required no special tools, jailbreaking, or elevated attacker access. The only requirement was physical access to an unlocked device (the owner's own device) or the ability to speak to the device while the owner was briefly away after having viewed the photo.

Defensive Implications

▶ Watch: Apple intelligence vulnerability that I found um a few months ago. (39:08)

For Users

• Invoke Siri critically: After viewing Hidden Album photos, be aware that Siri may retain contextual access to those assets for a window of time. Avoid activating Siri immediately after viewing sensitive content in the Hidden Album.
• Disable Siri on lock screen: Under Settings → Siri & Search, disabling lock-screen Siri access reduces the attack window for physical access scenarios.
• Disable ChatGPT integration: Under Settings → Apple Intelligence & Siri → ChatGPT, turning off the integration removes one downstream channel through which photos can be described aloud or to a third party.
• Force-quit Photos: Fully terminating the Photos app flushes the image conversion service's cache, eliminating the warm-cached asset window.

For Apple and Platform Engineers

The vulnerability class highlights a systemic challenge in iOS's increasingly complex inter-process coordination: authentication events are point-in-time, but data caches are temporal, and privileged system APIs do not always inherit authentication context from the originating UI.

Mitigations should consider:

• Context-aware API authorization: The Photos framework's intent-handling endpoint should verify whether the requested asset belongs to a currently-locked album, returning an appropriate access denial rather than the cached asset.
• Cache invalidation on re-lock: When the Hidden Album UI re-locks, photosimageconversionservice should be instructed to evict cached variants of Hidden Album assets from its working set.
• Authentication context propagation: System APIs accessed via Siri intents should carry and verify the authentication context of the originating album or container, not just the raw asset accessibility.

For Security Researchers

This vulnerability class — UI-layer authentication not propagating to underlying data layer accessible via privileged IPC — is likely present in other iOS features that combine content caching with assistant or automation integration. Researchers should examine other XPC services that retain warm caches and are accessible to assistantd or equivalent high-privilege daemons.

Key Takeaways

1. Authentication gates the UI, not always the data. Re-locking a UI view does not guarantee that cached content becomes inaccessible to all system components.
2. XPC caching windows create implicit exposure. Performance optimizations that retain content in memory after UI closure expand the window during which that content is accessible via non-UI paths.
3. Privileged daemons inherit broad access. assistantd has legitimately wide access to system APIs, but that breadth becomes a liability when those APIs don't enforce authentication context.
4. AI integration expands attack surface. ChatGPT integration and on-device image understanding create new downstream channels for sensitive content to be described or exfiltrated, compounding the impact of upstream information disclosure bugs.
5. Apple's ecosystem complexity is outpacing its trust model. As inter-process coordination grows more sophisticated to support features like Siri, Apple Intelligence, and cross-device sync, the attack surface at the intersection of these systems grows correspondingly.

About the Speaker

Richard Im is a security researcher who presented at DEF CON 33 as a first-time DEF CON speaker. His research focuses on iOS system internals, inter-process communication architectures, and the security implications of Apple's ecosystem integration features. The Hidden Album / Siri vulnerability chain he demonstrated reflects deep familiarity with iOS daemon architecture and the LocalAuthentication framework's interaction model with higher-level system services.