Then again, Apple’s marketing for the iPhone 5s made many claims of “subdermal fields”, “RF micro fields produced by the human body”, and how, as a result, it couldn’t be faked.
Except it could. Fairly easily. And without any remote pretense around the ‘emulate a live finger’. Just the fingerprint.
Much as I like Apple, these are pretty bold-faced deceptions.
Except, you know, they never actually said that.
The hack is to override the camera to ignore that signal. It is a rather unique idea and probably not something anyone even considered at Apple.
-- A LED shall light up when the camera is activated.
But what they should have implemented is:
-- It shall not be possible to activate the camera without the LED being lit, taking malicious third-party software into account.
The first requirement is obviously, and demonstrably, implemented by every camera (ignoring hardware defects regarding the LED). The second is, as proven by the paper, not fulfilled by any.
{EDIT: added the malicious part to the 2nd requirement}
-- There shall be a way for the user to physically obstruct the camera lens.
Apple used to have this in their standalone camera back in the day.
OS X allows non-privileged users to do that for some reason though...
So, upon (my incorrectly) presuming this was how it's already done in hardware and reading the headline of the article before I got to the text, I assumed they were turning it on and taking a single frame and turning it off fast enough that the LED was only on for a short enough time for the user not to be able to see it (or not notice).
Turns out the article claims they just reprogrammed the microcontroller to not turn it on in the first place. Of course that's a bad design, but you do need some more logic in there - the light needs to stay on for a minimum time when the camera is functioning so that the user can notice it.
This, too, is simple enough that it can be achieved without a microcontroller, but please don't presume that it's a simple fix. It's not just "put it in parallel".
The earliest standalone webcams, for instance Logitech models and the IndyCam that came with the Silicon Graphics 'Indy' workstation, had a 'door' that you could slide over the lens when not in use. Lenovo had this on their all in one PC's a few years ago but I don't think they kept that feature.
What was wrong with the slide-across lens cover?
You would think it would be an essential feature for some.
Overengineering usually refers to something that's not simple or elegant or a solution which represents more effort than the problem calls for. None of those factors seem to apply here.
The sliding cover is simpler and more secure.
It's not a software hackable thing because of the physical orientation of the LED. This is where the current designs get it wrong by making things too complicated (though they have their reasons).
edit: I'd note that these features we're talking about aren't mutually exclusive
I would be way easier to convince that a piece of plastic is harder to hack than a LED. For instance, there would be no embedded microcontroller to subvert.
Also, USB is a bus, you can't splice an LED into the power line of the USB going to a camera and conclude that when the LED is lit, the camera is recording. There's a lot of other traffic that could be happening beween the host and the device, that doesn't mean the camera is performing any recording. The reverse would of course be true, though (no light = no recording).
Looking at my current macbook lid, I don't how how that would physically fit. The camera would need to be recessed further into the lid to accomodate for the door.
> I would be way easier to convince that a piece of plastic is harder to hack than a LED. For instance, there would be no embedded microcontroller to subvert.
I'm inclined to believe that a mechanical sliding door would have a higher failure rate than an LED.
Absolutely not. The moving parts vs. no moving parts divide is pretty huge, and an LED is not a complicated thing.
> I would be way easier to convince that a piece of plastic is harder to hack than a LED. For instance, there would be no embedded microcontroller to subvert.
Having the LED in parallel on the power line is impossible to subvert without a soldering iron. I don't know why people are having trouble understanding this bit.
Perhaps to do this properly with a USB camera you'd need to give the camera its own USB controller. My god, who cares? The USB thing was just an example. The point is that you can wire in an LED such that when the camera has power, the LED has power.
> that doesn't mean the camera is performing any recording
The light today doesn't signify "recording," it just signifies that the camera is on.
The fact that you can forget it open, duh!
On the whole, I think this discussion focuses on the wrong 'problem'. If someone can gain access to your computer, taking control of the camera is just one of a whole host of nasty activities they could get up to - the real problem is securing against remote access in the first place.
http://www.wired.com/threatlevel/2010/10/webcam-spy-settleme...
http://www.pcmag.com/article2/0,2817,2386599,00.asp
> When the school district investigated the case, it found other incidents of webcam spying, and notified the students involved, including Levin. According to the lawsuit, filed in Eastern Pennsylvania District Court, Levin's younger brother commented on a light near the webcam that appeared to go on and off at odd times. His mother "dismissed the idea as absurd," but it appears he was right.
No longer plastering devices with semi-pointless LEDs would help. Harddrive activity? Wifi? Bluetooth? I don't think all these lights are really necessary. Throw one on the power cable maybe, and a few to backlight the keyboard, but otherwise only use them as indicator lights for things that are actually important to the standard user.
HDD light blinking? That means it's working correctly. Am I right?
In a lot of ways that is correct. Generally, when something is thrashing the hard drive it is making actual progress on its task, and its task is relativly short lived. This means that if your computer is going slowly, and the HDD LED is active, you can likely wait for the HDD LED to quiet down. In contrast, when your computer is going slowly (or not responding at all) and your HDD LED is off, it is much more likely that something is wrong and won't resolve itself.
If people can perform remote admin on machines 1000s of miles away without the need of green LEDs, I'm sure consumer tech will do just fine.
I'd agree that the LED is nonessential with HDDs -- you can just listen; and then you can even make out whether it's doing a lot of seeking or long continuous accesses, but you can't do that with SSDs.
One of my biggest gripes is how MS removed in Win7 the little connection icon in the system tray that shows when data is sent/received (it even split send/recv into two separate indicators, rather clever I think.) IMHO the trend of "simplification" is going too far. How about educating the users instead of making them more ignorant by hiding anything that they "wouldn't know about" (and making it harder for them to even start wondering about - and thus possibly learning)?
This to me seems more like an application of Occam’s razor. Hardware or Software malfunctioning seems much more likely than someone spying on you.
http://www.grafik.com/blog/2011/11/apple-sleep-function/
But yes, it's nice that they don't have a bunch of LEDs for everything.
There is already a common pop-culture shorthand for "now recording," the blinking red light. That's cheap and simple, and everyone already knows what it means, particularly when it's on a camera.
The real question, in my mind, is how the world-renowned user-experience and user-interface experts at Apple decided to use anything else.
I've heard that this was a serious flaw in Google's opinion, and they went through great efforts to ensure that the LED for the chromebook pixel was actually hard-wired into the camera's electronics. Which if true, shows that it's indeed possible.
Um. That would be exactly the point of doing it, in this case. The camera indicator (and the microphone indicator that every laptop should but currently does not have) should be completely inflexible.
What "flexibility" is added by having an indicator that only sort-of indicates, anyway?
As a compromise, the indicator could be wired-OR: software can turn on the indicator if it wants to, and it gets turned on if the camera is on, but software cannot turn it OFF if the camera is on.
Seems like, at worst, any sort of manufacturing inflexibility is solved the same way they usually deal with this stuff: A ribbon cable. Then you just have to worry about the physical security of the machine which is its own independent issue regardless.
Personally, I assumed they did it this way since it seems obvious (that's what I do in my own electronics projects) and much simpler than using a microcontroller to do it. I forwarded this idea to concerned friends. Looks like I'm eating my own words.
This is disappointing, and I expect Apple will redesign the cameras because of it.
The fact the camera controller could be reprogrammed from user space and then used to emulate a keyboard or mouse and bypass security / a virtual machine particularly devious, and shows how hard it is to trust even known hardware.
Still, it's a very, very cool hack: they reprogram a microprocessor to send commands to another microprocessor and configure it in such a way that it enters a state where the pin that the LED is connected to is irrelevant.
The article mentions that authorities have tools to bypass the LED. I would guess that the complexity is on purpose and wasn't supposed to be used by the general public. I bet the same is true for sound.
Of course many people made fun of it and mentioned "blah blah you are paranoid the LED cannot be manipulated and will always turn on ...".
Well ... here you go. Where are you now?
I wouldn't be surprised if someone-cough-you-know-who-cough had influenced the design for this to become a possibility. We know they are actively looking for opportunities like this. Go ahead, call me a paranoid again ... and next month when the story about how they did just that hits hacker news, I'll have an even better story to tell.
But in the research paper cited by the Wash Post[1], there's a whole section where the authors discuss their recommendations, see under "VIII. SECURE CAMERA DESIGNS". Including some specific suggestions of how you would implement this design in hardware.
[1] https://jscholarship.library.jhu.edu/bitstream/handle/1774.2...
Another option is to enable the LED when power is turned onto the module.
This interlock failed because the Micron sensor Apple used had software straps that could be reconfigured to have the sensor ignore its enable pin.
This is usually done at runtime, typically a bit of code that happens after the reset vector that puts the various config values into the appropriate registers that set up this routing and other customisable options.
In the case here, it's those other options that are the issue.
From the paper, Part IV(A):
> The Micron image sensor has a 16 bit configuration register, RESET (which is distinct from the #RESET power on reset signal). RESET is addressable from the I2C interface at address 0x0D in register page 0
And the hack involves setting that configuration register to unexpected values to enable functionality that bypasses the LED display circuit:
> Bit 7. Prevent STANDBY from affecting entry to or exit from the low-power state if set.
> Bit 6. Prevent STANDBY from contributing to output enable control if set.
(where STANDBY is the signal/pin to which the LED is connected)
So the controller assumes that the physical STANDBY pin will always accurately reflect/control the state of the sensor, which is not necessarily the case if it's been disabled by re-configuration.