Apple Closes iSight Security Hole
Gruber Duckie writes "Apple's security update 2006-008, posted yesterday, is a little more interesting than it sounds. According to information (and a demo!) posted at Macslash the "information leak" mentioned in Apple's advisory actually makes it possible for a web site to send whatever your (isight) web cam sees up to the server. I'm glad they fixed this quickly."
Of course, an application running on your local machine can do anything it wants. So it's not surprising that a malicious Java applet/application could, well, do malicious things.
/System/Library/Extensions/Apple_iSight.kext /System/Library/QuickTime/QuickTimeUSBVDCDigitizer .component
For those who don't know, a Quartz Composer composition saved as a QuickTime movie can display the iSight image locally. Since QuickTime movies can be embedded in web pages, you can create a movie that displays the *local* iSight image back to the person, locally. Nifty, right?
But is interesting is that via Java hooks in QuickTime for Java, a Java applet could be used in conjunction with this Quartz Composer movie to do anything that a Java applet could instruct QuickTime to do - including take a shot of whatever is being displayed in the QuickTime movie - and then do anything else a Java applet could be designed to do - in this case, potentially send that image somewhere.
So, this could be done on any platform with a camera, since all it is is malware running to perform a specific task.
But what's more interesting is:
- All Mac OS X systems will always have QuickTime, and thus always have the capability to run such a composition
- All Apple laptops have cameras that cannot be easily disabled (of course (unless the LED is burnt out) due to the way the iSight is set up electrically, the green light will always be on when in use)
The ubiquitousness of iSight camera is what makes this little trick interesting. It also raises issues such as: why didn't Apple offer an option to delete the camera (especially for government/military customers, as other vendors, like Palm, do), and why didn't Apple offer a mechanical shutter for the iSight on all models?
In any case, it's fixed with Security Update 2006-008, but a legitimate Java application, i.e., one you trust, could still do just that. Which stands to reason, of course, since code running on your machine - even if instantiated by a web page - can really do anything that you have permission to do, including delete files. That's the nature of applications.
One other note: you can indeed disable the iSight by (re)moving:
In sum, the reason why this is interesting is because of the ubiquitousness of the Apple iSight on Apple laptops and the fact that it's ready for use. But, someone still has to visit a malicious site and run a malicious Java applet - user interaction: the hallmark of Mac OS X vulnerabilities!
And if you had read the Security Advisory, you would have seen that the problem they were fixing was about data being sent to the server and was fixed. They did not remove quartz composer functionality from Quicktime movies, so the movies you can download that show you to yourself, possibly with some effects added, still work (and are still a little creepy), but they only display the picture locally. What they did was remove the functionality from unsigned Java applets to embed such movies, because those applets could take the image produced by Quicktime and send it back to the server, which was a real problem.
What they did was remove the functionality from unsigned Java applets to embed such movies, because those applets could take the image produced by Quicktime and send it back to the server, which was a real problem.
Yeah, too bad Sun announced yesterday a flaw in all their runtime environments that allows untrusted applets to access data from trusted applets. I don't think Apple has squashed that one, so there is still some potential for mischief.
Psst, hey anonymous troll. MS used to release patches at random intervals as soon as they were ready as well. They did that for many years. Their huge corporate clients asked them to consolidate the patches to a regular interval so that their tech staff could test and roll them out in synch, saving tons of time testing all their regular and custom built in-house apps with each patch that MS released to make sure nothing broke, then rolling them out to thousands of machines, then testing all their stuff again 3 days later when another patch rolled out, then 5 days later when another patch rolled out, etc, etc.
Patch Tuesday was because of customer requests. This isn't 'competition' against patch tuesday.