Slashdot Mirror

← Back to Stories (view on slashdot.org)

Apple Closes iSight Security Hole

Posted by CmdrTaco on from the nobody-wants-to-see-me-naked dept.

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."

1 of 213 comments (clear)

  1. Re:Why this is interesting by daveschroeder · · Score: 5, Informative

    I should also note that, for government/military customers, Apple does have a contractor that can physically disconnect the iSight and internal microphone as part of the procurement process, and meets GSA schedules and requirements for "no-camera" or "no-microphone" environments; additionally, infrared, Bluetooth, and AirPort can also be disabled. This does not void any waranties. That contractor is:

    Holmans
    6201 N. Jefferson Ave
    Albuquerque, NM 887109
    Tony Greiner
    505 343 3529
    tgreiner@holmans.com

    GSA schedule GS-35F-0341N
    DOE authorized (LLNL and LANL)
    DOE "L" clearance personnel

    For individual customers, any Apple Authorized Service Provider can disconnect any or all of the above components, and are happy to accommodate such requests. Such requests also do not void warranties.

    Again, these components can all be disabled by software means in managed environments where physical disconnection/removal of the device(s) is not a requirement.

    I should note that this trick could technically be done any any platform with a camera: run malicious software designed to send imagery from an attached camera somewhere. But in the case of Mac OS X on Apple hardware, it becomes interesting because Apple has already done all the work to drive the camera and display within QuickTime (via Quartz Composer, the integrated camera and drivers, and so on), and then QuickTime for Java can be used via a malicious Java application or applet (which still has to be run, of course) to send images remotely. After Security Update 2006-008, a Java applet (unless it is a signed applet that is specifically allowed by the user) can no longer make such such calls to QuickTime for Java.