Slashdot Mirror


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

2 of 213 comments (clear)

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

    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.

    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: /System/Library/Extensions/Apple_iSight.kext /System/Library/QuickTime/QuickTimeUSBVDCDigitizer .component

    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!

    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.