16 ms·
I worked on AppKit's persistent state feature. One of its primary uses is persisting UI state across app restarts, for example when performing a software update
by ridiculous_fish 4y ago
I worked on AppKit's persistent state feature. One of its primary uses is persisting UI state across app restarts, for example when performing a software update. Simply writing out memory to disk would "persist" data like Mach ports or file descriptors, which would no longer be valid when the app is re-launched.
- benreesman 4y agoMakes sense! Thanks for the explanation.
- amluto 4y agoWould it be practical to prevent apps from writing to other apps’ persisted state?
- ridiculous_fish 4y agoYes of course, by design apps write their state into their own sandbox in the filesystem, and trust the OS to enforce security boundaries.
- amluto 4y agoThen how does the entitlement escalation part of the exploit work? The writeup sure makes it sound like any app can write to the persisted state of another app.
- ridiculous_fish 4y agoSandboxed apps cannot write into the container of other apps unless the user explicitly allows it. Here the bug is that OpenAndSavePanelService, which is privileged, was decoding state from the app it was acting on behalf of. An app can save malicious objects into its own serialized state, and then it will be injected into OpenAndSavePanelService, leading to a sandbox escape. The fix is for the service to stop decoding state.