4 ms·

I would be an order of magnitude less concerned with camera/mic access, compared to perfect historical proof of my usage and communication patterns. Exploits o

by 58x14 5y ago

I would be an order of magnitude less concerned with camera/mic access, compared to perfect historical proof of my usage and communication patterns. Exploits often feel like pathogens, probably why they share the term virus. If a virus has a high mortality rate, contagion is lower, because it frequently kills the host before it can spread. Similarly, I think a 'complete device compromise' is much more likely to be identified, prioritized, and patched. The vulnerabilities mentioned here represent the highest severity without an immediately noticeable fallout. Props to the researcher. P.S. I wonder if the researcher's Russian nationality (assumed from their other post) had any impact on their lack of payout.

pvg 5y ago
It's hardly 'perfect historical proof', not to diminish the seriousness of the vulnerability. But more importantly, the mechanism matters a great deal. This particular vulnerability requires the install of a malicious app, a much higher bar than a 'drive by' exploitation. This leaves a trace and exposes the attacker to consequences. No (statistically speaking) app producer with any interest in continuing to use the platform would deploy such an exploit even if they had access to it.
- hsbauauvhabzb 5y ago
  I’ve always been curious how many developers might drop this in their code but only activate against potentially valuable targets
  - pvg 5y ago
    I'd think also almost zero. A lot of sleazy data collection operates under at least some fig leaf pretense of user consent, in this case there's none. Once the vulnerability is discovered, Apple could find out if you've deployed such code more or less ever. Then you'd probably have problems bigger than just a contractual dispute with Apple.
    - tonypace 5y ago
      Maybe some devs are allowed to do this. And that's why it wasn't patched.
- akiselev 5y ago
  > This particular vulnerability requires the install of a malicious app, a much higher bar than a 'drive by' exploitation. It's a much higher bar when it's a targeted attack but not necessarily if it's a dragnet like when a malicious party buys a browser extension from the creator to harvest user data. The only real difference between the two scenarios is iOS's significantly stricter review process and sandbox - if this exploit can bypass both [1], it doesn't matter whether the malicious developer can be traced because it'll just be some indie dev who just sold his username/password and signing keys for $X0-Y00k to some shell corp in the Bahamas. [1] Are these exploits detectable through static analysis or some other automation? (I have no idea)
  - pvg 5y ago
    The 'only real difference' is a pretty big difference - the iOS developer is much more strongly identified. It's also not the only difference - what you can do with the access is different and what you end up doing with the access is different. But in both cases, there are strong disincentives not to do very overtly malicious shit - few extension takeovers go around stealing your online banking password, even though they could. A drive-by exploit has a lot fewer of these constraints.
  - saagarjha 5y ago
    Dumb implementations can be caught via static analysis. Smart ones are not going to be caught until Apple realizes they are exploiting people and reverse engineers them by hand.
- funcDropShadow 5y ago
  To exploit this you only have to infect one of the many dependencies off user installed app. It is not true that the attacker has to forge an identity in the App Store. It is enough to insert your code somewhere along the whole software supply chain. And that can be long, think about ReactNative apps using NPM dependencies.
- jtbayly 5y ago
  > No (statistically speaking) app producer with any interest in continuing to use the platform would deploy such an exploit even if they had access to it. Except Facebook. Or another behemoth that felt they could weather Apple's wrath if it ever came to it. Or a company that Apple had granted special permission to do this, like they did with Uber.
  - pvg 5y ago
    Apple killed a bunch of FB's tracking a few months ago and the story is still making the rounds and is on the front page as we speak. The point isn't that this isn't a serious vulnerability or is somehow unexploitable. It's just that there's a great deal of friction in exploiting it for relatively paltry returns. Nobody is going to get into a spat with Apple and invite regulatory and law enforcement attention to traceably and with undeniable intent steal your contact list. Nobody is going to (like another commented hypothesized) launch a supply chain attack to steal your contact list with this vuln. At that point you'd find a better vuln. This one isn't all that much better than just misleading people into giving you contact list permission. The OP is saying it's somehow worse than drive-by or low-interaction vulns that own up entire devices and have been repeatedly found in the wild. I don't think that holds up.

by 58x14 5y ago

pvg 5y ago

It's hardly 'perfect historical proof', not to diminish the seriousness of the vulnerability. But more importantly, the mechanism matters a great deal. This particular vulnerability requires the install of a malicious app, a much higher bar than a 'drive by' exploitation. This leaves a trace and exposes the attacker to consequences. No (statistically speaking) app producer with any interest in continuing to use the platform would deploy such an exploit even if they had access to it.

hsbauauvhabzb 5y ago
I’ve always been curious how many developers might drop this in their code but only activate against potentially valuable targets
- pvg 5y ago
  I'd think also almost zero. A lot of sleazy data collection operates under at least some fig leaf pretense of user consent, in this case there's none. Once the vulnerability is discovered, Apple could find out if you've deployed such code more or less ever. Then you'd probably have problems bigger than just a contractual dispute with Apple.
  - tonypace 5y ago
    Maybe some devs are allowed to do this. And that's why it wasn't patched.
akiselev 5y ago
> This particular vulnerability requires the install of a malicious app, a much higher bar than a 'drive by' exploitation. It's a much higher bar when it's a targeted attack but not necessarily if it's a dragnet like when a malicious party buys a browser extension from the creator to harvest user data. The only real difference between the two scenarios is iOS's significantly stricter review process and sandbox - if this exploit can bypass both [1], it doesn't matter whether the malicious developer can be traced because it'll just be some indie dev who just sold his username/password and signing keys for $X0-Y00k to some shell corp in the Bahamas. [1] Are these exploits detectable through static analysis or some other automation? (I have no idea)
- pvg 5y ago
  The 'only real difference' is a pretty big difference - the iOS developer is much more strongly identified. It's also not the only difference - what you can do with the access is different and what you end up doing with the access is different. But in both cases, there are strong disincentives not to do very overtly malicious shit - few extension takeovers go around stealing your online banking password, even though they could. A drive-by exploit has a lot fewer of these constraints.
- saagarjha 5y ago
  Dumb implementations can be caught via static analysis. Smart ones are not going to be caught until Apple realizes they are exploiting people and reverse engineers them by hand.
funcDropShadow 5y ago
To exploit this you only have to infect one of the many dependencies off user installed app. It is not true that the attacker has to forge an identity in the App Store. It is enough to insert your code somewhere along the whole software supply chain. And that can be long, think about ReactNative apps using NPM dependencies.
jtbayly 5y ago
> No (statistically speaking) app producer with any interest in continuing to use the platform would deploy such an exploit even if they had access to it. Except Facebook. Or another behemoth that felt they could weather Apple's wrath if it ever came to it. Or a company that Apple had granted special permission to do this, like they did with Uber.
- pvg 5y ago
  Apple killed a bunch of FB's tracking a few months ago and the story is still making the rounds and is on the front page as we speak. The point isn't that this isn't a serious vulnerability or is somehow unexploitable. It's just that there's a great deal of friction in exploiting it for relatively paltry returns. Nobody is going to get into a spat with Apple and invite regulatory and law enforcement attention to traceably and with undeniable intent steal your contact list. Nobody is going to (like another commented hypothesized) launch a supply chain attack to steal your contact list with this vuln. At that point you'd find a better vuln. This one isn't all that much better than just misleading people into giving you contact list permission. The OP is saying it's somehow worse than drive-by or low-interaction vulns that own up entire devices and have been repeatedly found in the wild. I don't think that holds up.