Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> 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)



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.


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: