Replies

As the article says, this was implemented on older generation MacBooks, not current models.

However, on the vulnerable models, it appears that in fact you don't need remote administrator privileges, nor do you need to reflash the EPROM. You just need to run the iSeeYou app. Caveat: I have not tried this on an actual machine myself, as that seems unwise; but this is the claim made in Johns Hopkins article.

The reprogramming of the firmware is said to be done with system calls and USB functionality, and no mention is made of attaching additional hardware to reflash the EPROM, nor is physical access to the machine said to be required.

Here's what the article says:

Threat model. To mount our main attack where we capture video without any external indication to the victim, we assume that an attacker is able to run native code on the victim’s computer as an unprivileged user. Further, we assume the code is unencumbered by defenses such as Apple’s App Sandbox which is used for applications downloaded from the Mac App Store but by little else. This assumption is quite mild...

...

We stress that our main result — disabling the iSight LED — only applies to the first generation internal iSight webcams and we make no claims of security or insecurity of later models...

It's clear that they're saying that this is a security issue with 1st-generation iSight webcams.

You do need to convince someone at the machine to run the app, but that's generally not too hard to achieve (people download things frequently, they open email attachments, etc., etc.).

They do go on to show how you can use this to do more than bypass the webcam LED -- you can actually run arbitrary code (as an unprivileged user). This extra step requires some additional user authorization. (I think a compromised video conferencing program would be sufficient, but I'm not sure.) However, this extra authorization isn't needed for the webcam LED trick.

By the way, my post was not at all anti-Apple or anti-Unix. Experience suggests that Windows machines have many more vulnerabilities. However, this particular hack happens to have been on a Mac.

Anyway, if I'm wrong, please point out where the article says that anything more is required than running an unprivileged program on a target machine of the correct vintage.

Threat model. To mount our main attack where we capture video without any external indication to the victim, we assume that an attacker is able to run native code on the victim’s computer as an unprivileged user. Further, we assume the code is unencumbered by defenses such as Apple’s App Sandbox which is used for applications downloaded from the Mac App Store but by little else. This assumption is quite mild...

Thank you for pointing that out. I read through the entire paper except the citations. Amazing work though it is at best a Trojan in that they do have to get the user to install and run the malicious App so that part of it is activated in a VirtualBox in a virtual OS that is not OSX. One other caveat seems to be, reading between the lines, is that user had to have administrator privileges. . . and the attacker had to have it too because they mentioned the necessity to use SUDO. Had the victim user been operating as a Standard User as is the recommended practice, this would not have worked. Couple of other points. . . G5 computers cannot access the App Store, which they mention is a prerequisite for this to work, although there are other modalities to get the iSeeYou app on target G5. Biggest is the VirtualBox necessity to be running. . . That is a killer and sort of takes us back to the preparing the machine in advance to be invaded before it can be. How many Mac users are going to be running the appropriate guest OS under VirtualBox which has full root privileges (that's actually how the hardware reprogramming of the iSight camera EPROM is accomplished)?