Ah I remember a very similar bug. I remember back in the day, I'd use a fork of TheBackdoorFactory so that the replaced app still functions as usual and in the background request permissions & stuff to then be able to do stuff like key logging. Apple also responded with won't fix, but I think at some point silently patched it.
Not sure I understand the risk here, and seem to agree with Apple this is a non-issue. You already have code execution in order to exploit this. You don’t get the cryptographic identity of the victim app so you can’t steal keychain secrets. How is this any different than just bundling your own second-stage malware with a victim bundle ID, then using your existing code execution to remove the quarantine flag and then run the second-stage malware? Or just doing the evil things with your existing code execution?
Instead of replacing the executable, couldn’t it be wrapped and augmented, so it’s just running payload in the background with the original permissions and keychain access? It does seem pretty bad.
No — the victim app is code signed and the permissions and keychain access are tied to the cryptographic identity used to code sign. Replacing or wrapping or whatever here must happen with a different cryptographic identity (unless you actually exploit the victim app itself which is a whole different thing).
If you look at the App Management pane in the Privacy & Security section of System Settings, it literally says, "Allow the applications below to update or delete other applications."
Somehow, Apple missed the "delete" part of that. Apple software engineering failed by allowing the bypass, and Apple Product Security failed by misunderstanding the issue.
If an attacker can simply delete and replace an app, then App Management might as well not even exist.
Not what I immediately expected: it doesn't give you the cryptographic identity of the target app, but it does read a lot like a high-quality phishing attack where you get to e.g. issue permissions prompts with the totally specific visual identity of the app that you dropped your binary into. A highly technical user might, if we're very lucky, question why they're being asked for permissions again, but an ordinary user never would, for sure. If Apple is going to attest to identity, they need to make sure it's combinatorially right.
I totally understand why the author would love to see this fixed. But I'd honestly continue to go the other direction, (software freedom), and say that I rather wish that we would instead make this whole architecture less rigid. Apple seem to have looked at Windows Vista era UAC... and taken all the worst parts of it.
I tend to think that if we were to give the user a lot more information: people aren't as dumb as Apple treats them. Absolutely many users just do not care, but I think that making the UX as terse as it is is half of what's doing the damage.
---
Imagine:
A new app downloaded from (signal.org)[1] would like to launch.
The app is Signal by the (signal.org)[2] team, [which MATCHES where you downloaded it from][3].
[Signal and signal.org are extremely popular, having been seen N million times this month][4]
You may wish to check all of this information before launching it, but this is a [COMMON][5] app.
---
[1]: this would be the quarantine attr's source
[2]: this would be from the signing identity – but no need to explain that
[3]: I would literally check this and display the prose
[4]: yes, this involves a bunch of localization strings
[5]: This is where you'd have to decide whether you want to provide an opinion or completely disclaim liability, like Apple has had a tendency to do.
This would leave the door open to incrementally more relaxed versions of this posture, including allowing an unsigned app, or less common apps with more alarming language, up to and including color, to communicate how different that is. Even just a (localized to region) traffic light style appearance would go a long way. I totally acknowledge that, for example, the Chrome folks decided that they have to hide and bury this, because users can't be trusted not to proceed anyway when advised to do so. But this is why I think spelling it out in more detail would go a long way, which Chrome never (competently) did. Even with HTTPS certificates, I'd rather write an EXTREMELY high-quality explainer paragraph to the user about WHAT they're accepting.
Ah I remember a very similar bug. I remember back in the day, I'd use a fork of TheBackdoorFactory so that the replaced app still functions as usual and in the background request permissions & stuff to then be able to do stuff like key logging. Apple also responded with won't fix, but I think at some point silently patched it.
Not sure I understand the risk here, and seem to agree with Apple this is a non-issue. You already have code execution in order to exploit this. You don’t get the cryptographic identity of the victim app so you can’t steal keychain secrets. How is this any different than just bundling your own second-stage malware with a victim bundle ID, then using your existing code execution to remove the quarantine flag and then run the second-stage malware? Or just doing the evil things with your existing code execution?
I would use "Defense in Depth" as an argument to addressing this issue.
Instead of replacing the executable, couldn’t it be wrapped and augmented, so it’s just running payload in the background with the original permissions and keychain access? It does seem pretty bad.
No — the victim app is code signed and the permissions and keychain access are tied to the cryptographic identity used to code sign. Replacing or wrapping or whatever here must happen with a different cryptographic identity (unless you actually exploit the victim app itself which is a whole different thing).
If you look at the App Management pane in the Privacy & Security section of System Settings, it literally says, "Allow the applications below to update or delete other applications."
Somehow, Apple missed the "delete" part of that. Apple software engineering failed by allowing the bypass, and Apple Product Security failed by misunderstanding the issue.
If an attacker can simply delete and replace an app, then App Management might as well not even exist.
Not what I immediately expected: it doesn't give you the cryptographic identity of the target app, but it does read a lot like a high-quality phishing attack where you get to e.g. issue permissions prompts with the totally specific visual identity of the app that you dropped your binary into. A highly technical user might, if we're very lucky, question why they're being asked for permissions again, but an ordinary user never would, for sure. If Apple is going to attest to identity, they need to make sure it's combinatorially right.
I totally understand why the author would love to see this fixed. But I'd honestly continue to go the other direction, (software freedom), and say that I rather wish that we would instead make this whole architecture less rigid. Apple seem to have looked at Windows Vista era UAC... and taken all the worst parts of it.
I tend to think that if we were to give the user a lot more information: people aren't as dumb as Apple treats them. Absolutely many users just do not care, but I think that making the UX as terse as it is is half of what's doing the damage.
---
Imagine:
---[1]: this would be the quarantine attr's source
[2]: this would be from the signing identity – but no need to explain that
[3]: I would literally check this and display the prose
[4]: yes, this involves a bunch of localization strings
[5]: This is where you'd have to decide whether you want to provide an opinion or completely disclaim liability, like Apple has had a tendency to do.
This would leave the door open to incrementally more relaxed versions of this posture, including allowing an unsigned app, or less common apps with more alarming language, up to and including color, to communicate how different that is. Even just a (localized to region) traffic light style appearance would go a long way. I totally acknowledge that, for example, the Chrome folks decided that they have to hide and bury this, because users can't be trusted not to proceed anyway when advised to do so. But this is why I think spelling it out in more detail would go a long way, which Chrome never (competently) did. Even with HTTPS certificates, I'd rather write an EXTREMELY high-quality explainer paragraph to the user about WHAT they're accepting.