By Graham K. Rogers

Two researchers at Johns Hopkins University have created a bit of a stir in the last day or so with the publication of an article that showed it was possible to turn on the iSight camera remotely in some Macs, without the green LED being lit. They also produced an application to do this and, like good guys, an app to defend from the exploit which is available if needed.

Some may remember reports about the Lower Merion school that was shown to have taken some 56,000 photographs of students. One, who was accused of taking drugs (it was Mike & Ike's), sued and the school district had to pay out some $600,000, plus $10,000 to another student (Kashmir Hill, Forbes).

As a result of the interest this case produced and a general interest these days in security questions, two researchers at Johns Hopkins University - Matthew Brocker and Stephen Checkoway - had a look at the iSight camera in the type of Macs in the school. Although the LED light operated when the Lower Merion Macs were used, a question arose about whether this could be done without this being shown.

Brocker and Checkoway decided to find out if and how this could be done. As we now know with revelations about the NSA, they have been doing it for some time.

As is correct and responsible when the research was complete, they sent the information they discovered about iSight security to Apple in July this year, followed (in August) by details of a Virtual Machine Escape that could be used to control USB devices on Macs, like the older iSight camera. Apple did make further inquiries, but (not a surprise) did not tell them about any fixes.

I had a look earlier today at the published research which I downloaded from Johns Hopkins. The first link I found was to the Abstract, but I also read through the several pages of the full article which is available via the Abstract. It does contain a lot of technical information.

Outlining the many problems with cameras in other types of computers, the researchers picked up on the point that it might be possible to actuate the iSight camera with no LED indication. The same insecurity could apply to USB devices using the same Cypress chip.

The construction of the early iSight units is such that, when a camera operates, an electric signal passes and the green LED - installed between the image sensor and the microcontroller - lights up. They set out to reprogram the iSight microcontroller with "arbitrary, new firmware." Their description outlines the five points that they were concerned with technically:

• The Architecture of "previous generation" products (including G5 iMac, and Intel-based Mac notebooks produced until "roughly 2008"). They point out that this does not include the 2nd generation iSight or the later FaceTime cameras, but leave the question open as to whether they might be liable to exploits in the future.

  This is one for Apple to make sure of.

• How to bypass the iSight hardware interlock and create the proof-of-concept iSeeYou application.

• How to create the virtual machine escape (to control a computer by external means).

• Creation of the OS X extension to defend against such attacks (iSightDefender).

• Outline how to create a secure camera module.

Some assumptions were made concerning installation of malware that I am not as sure about as the researchers. Users who do not click on everything and only install apps from the MacApp Store (or from trusted sources) should not be affected.

In the background, Brocker and Checkoway outline several interesting Apple and Intel weaknesses. As these have all been extensively researched and reported, steps should have been taken by the responsible companies.

The technical description of the iSight camera and its related components, plus software and firmware, show how carefully the research has been carried out. The image sensor can be "influenced" by its interface and by several hardware signals.

Particularly important are RESET and STANDBY signals. The LED is linked to the STANDBY input, but this signal can be bypassed by resetting certain pins on the image sensor. By modifying the firmware, the LED light will display in normal use, but iSight can be signalled to operate without the LED.

When installed, their proof-of-concept, iSeeYou, can be used to reprogram the iSight camera and the LED light does not operate. However when the app quits, the behaviour returns to normal. However the behaviour might also be created by using a Virtual Machine approach via malware. As well as reprogramming iSight, it is pointed out that any EZ-USB device could be so used.

There are several defenses, including hardware and OS modifications, although the best solution would be a change of iSight hardware (which has now been done with the newer machines). However, as above, there is no iron-clad guarantee that another such exploit may not be developed in the future. The tape over the lens, or ripping the camera out (as The NSA has suggested), may be the only sure ways to avoid surreptitious surveillance.

As a way of creating another defense, Matthew Brocker and Stephen Checkoway examined Apple's own protections, and developed iSightDefender to prevent "particular USB device requests from being sent to the camera." Its use means that an attacker would need root privileges to reprogram iSight. The application and its source code are available for download. There are no suggestions or recommendations from me on this, but I am not going to install it, even though I still have a 2007 MacBook Pro that could be liable to such an exploit.

The FaceTime cameras in the latest Macs, such as the MacBook Air do not use USB, but PCIe which is significantly more secure. Nonetheless, with the threats to personal computing being real - and growing - there are four recommendations from Brocker and Checkoway here:

• Store the firmware in nonvolatile storage on the camera module.

• Use a microcontroller which can block unwanted firmware reprogramming attempts.

• Firmware updates, if necessary, should be cryptographically signed and the signature verified before applying the update.

• Require root/administrator privileges to send reprogram- ming requests.

The first pair look at the way camera weaknesses can be exploited with firmware. The second pair deal with increased security when it comes to installing any necessary firmware updates. This might be accomplished by including any such changed firmware in an update to OS X (or other operating system, depending on the computer)

They note that the widely used EZ-USB is "inappropriate for use in any system where security is a consideration." The Discussion has a number of other interesting exploit possibilities (and realities) that are known to be risks for all platforms.

Matthew Brocker and Stephen Checkoway will be extending the research to later generations of cameras in Macs as well as in other brands of laptops.

Graham K. Rogers teaches at the Faculty of Engineering, Mahidol University in Thailand where he is also Assistant Dean. He wrote in the Bangkok Post, Database supplement on IT subjects. For the last seven years of Database he wrote a column on Apple and Macs.