That is damn clever to be sure— but calling it a "very real" threat is a little sensationalist. In this day and age, an attack involving physical access is of little relevance to consumers. In fact, replacing the battery on a MacBook is only marginally more difficult than replacing the hard drive. Of course I'm sure various government organizations are going to have some stern questions for Apple nevertheless...

Anyway, they've already fixed this vulnerability in my MacBook Air. I'm not worried.

It's kind of a degree beyond the traditional 'physical access' attack though. This means that if you buy a replacement battery for your MacBook, it could contain malware. In fact, even the legitimate battery you purchased from Apple could maintain malware, if someone slipped it in at the manufacturer. You could say that traditional vetting of manufacturers and security processes would prevent this, but really, who's going to think of the potential for a battery to compromise your security?

Then so could the replacement hard drive, any USB sticks you buy, any USB connecting peripheral, etc.

Not quite, there is already heavy protection against nasty peripheral devices.

I don't think so. Certainly not for any peripheral that is allowed to do DMA. Though plugging in a malicious firewire peripheral is a lot more practical than replacing the battery...

http://www.hermann-uwe.de/blog/physical-memory-attacks-via-f...

When there's already semi-legitimate worries that the Chinese government could have spyware chips installed on computer motherboards, this would be a lot more malicious, easier to perform and initially far less detectable.

From the post, the author says the battery could repeatedly install malware or spyware to your computer.

What would be more worrying is if someone found a way to hack directly to you battery. IE a virus you get installs itself to your battery as its resurrection method rather than in a system file. Worse yet would be if someone maliciously wrote a virus that caused your battery to overcharge a month down the road.

Imagine all those stupid MSN virus' if they could fry your laptop battery.

You don't need a government's resources. You need a programmable firewire device, like an embedded Linux device. You also need ten seconds of physical access to their FireWire port. That's a lot easier than hacking a battery and convincing the target to use the battery.

Even Charlie Miller says he doesn't know how you would embed malware on a device using this attack.

That's of course beyond the point that a great many other things you buy at a computer store could more easily contain malware.

How is that different from hacking the ASIC of the network card?

http://www.links.org/?p=330

This attack wouldn't require physical access. The researcher analyzed a firmware update that Apple had sent out to reverse engineer the passwords, which he then used to poke around the code in the battery.

Theoretically, malware could get onto a machine by whatever means, then use the battery as a nasty hiding place, or target the battery itself.

EDIT: It should be noted that a second vulnerability will be needed to get code from the battery into the machine.

I have zero familiarity with Charlie's research, but I have a (passing) familiarity with battery controllers, and the malware-hiding-on-battery thing doesn't add up to me. How does the battery access host memory? It's not like these things do DMA, right?

That's the second vulnerability that would need to be found. Maybe it's locked down and we're okay. Or maybe the code in OSX that reads the battery's health and capacity has a buffer waiting to be overflowed.

My impression is that the "second vulnerability" Charlie is talking about is the remote->kernel transit needed to allow you to talk to the battery in the first place.

This sounds bi-directional, though (as in you could run some software with a payload that overloads/overheats your battery).

Which is non-threatening for the inverse reason; somebody who owns my OS can probably damage my hardware if they want to. Ruining the SSD in my Air would mean a replacement just as surely as trashing the battery, and would be a lot easier.

Now in fairness, being able to make something in my computer start a fire is on a way different level. But we're getting that from "Miller said that it might even be possible to overload the battery so that it catches fire"— he hasn't done it, and doesn't even know if it's possible. My money is on there are some lower-level safeguards to prevent bugs in the firmware from causing fires, even if they do ruin the battery. Li-ion batteries are designed physically with the knowledge that they're a ticking timebomb waiting to go off, and I can't believe that nobody at Apple has started from asking "But what if I were actually trying to make it explode."

Indeed, according to the article, it could be bidirectional:

>Using that password, Miller said that he has been able to do almost anything from giving false readings to the charger and the OS to ruin the device, to completely rewriting the firmware.

I don't know if it would be possible to make the battery burst into flame or explode. After the Sony battery fiasco, I'd expect there to be some kind of hardware interlock preventing short-circuits. However, it is possible to overwrite the battery firmware to prevent the battery from being charged, thus turning your Macbook Pro into a very small form-factor desktop.

I had an internship at a company that made lithium battery packs. The control boards on the packs have primary cell protection provided by a specialized micro controller that monitors cell voltages and prevents over/under charge levels and monitors current, however they also have secondary protection ICs that are hardware based that will shut down the pack should the cells reach dangerously high levels, as well as fuses to prevent dangerous levels of current.

Net result, changing battery firmware can reduce usefulness of battery (higher charging degrades cell life, blow fuses etc) but the packs should have hardware based protection from being a safety hazard

Actually, Macbooks use lithium polymer batteries which are highly explosive when overcharged (http://www.youtube.com/watch?v=0MiM2E6pvfg). So by telling the OS that a battery is not charged when it really is can cause it to explode.

That's a bare LiPo cell wired directly to current— not a good demonstration of how a well-designed battery pack would behave, even one with malicious firmware.

Yeah, _access is ownership_, after all.

background: Mac boots from all media except retail OS X installation media. I try everything including paying $50 to be told "we don't know"... when I resort to resetting the SMC.

observation: Turns out, the battery is secured with Y-cut-head screws, rather than the traditional Phillips screws of the hard drive.

So not only is the hard drive a more obvious target... it's considerably easier to get to in my opinion. (Unless people have Y-shaped screwdrivers lying around, who knows).

SMC reset is done with a key combo on newer MBP's without the latch bottom, you don't have to pull the battery.

You're right, I missed the fine print. Thanks for getting me to look again: http://support.apple.com/kb/ht3964 (look for "Resetting the SMC on portables with a battery you should not remove on your own", how silly of me, I shouldn't remove it because they used proprietary screws)

Regardless, I think it still speaks to the notion that the battery is harder to attack than the hard drive other than the more obvious reasons.

I just wanted to mention that I'm tracking every single connecting device onto my city's main international airport's WIFI network (for analytics). I think this is a great gauge on the popularity of portables. And of millions of connecting devices, Mac portables and iDevices represent 63% of it all! It's definitely more than I would have thought, and it's quite interesting. You might think, oh right iDevices, but the breakdown is 60% Macbooks, 3% iPhones, 0.6% iPads.

That is quite interesting and would be worth a blog post of it's own. I have noticed that it's less of a hassle to sit down, open macbook type password and be either on the network or at least able to get to the login/TOS acceptance page than with any Windows or Linux laptop I've dealt with.

It would be interesting to see real data from a location with a random though not unbiased sample (air travelers probably skew richer and younger than the average population).

Posting anonymously because I have some industry experience with this. I have designed circuit boards to protect lithium-ion batteries in notebooks. (By the way, all this information could be learned from publically-available data sheets on Texas Instrument's website)

The is a complete non-story, and I will tell you why:

1) Regarding installing "malware" on a battery. I have never worked with a battery monitoring ASIC that contains a general purpose micro controller. I have worked with Texas Instruments notebook battery monitors, and none of the ones I have worked on can run general purpose code. They have registers that the host can poll to get information about the battery, but there is no way to load code onto them. The researcher keeps talking about "reverse engineering the firmware" of the battery. Maybe things have changed recently, but I have never seen actual general-purpose firmware in a battery. Limits and calibrations settings yes, but firmware no.

2) Regarding any potential safety issues: Every battery controller board has a secondary battery protection IC. This IC has no firmware at all, and is a purely hardware based way to detect over-voltage, under-voltage, or over-temperature conditions. This can not be overridden in any way (it does not sit on a communication bus). Usually when this secondary protection kicks in, it will permanently disable the battery. In addition, each individual cell has a "PTC" (positive-temperature-coefficient) resistor in series that will isolate the cell if too much current is drawn. (Some battery designs might use a fuse instead.) This is in addition to the main battery fuse, and the controllable FETs.

These batteries are designed with multiple levels of protection. Any one of them failing (including the main monitor ASIC) will not make a battery catch on fire.

3) As far as I remember, you can't really use the SMBus of a notebook without having root access. I could be wrong here though.

4) Finally, this is by no means limited to only Macs. Every PC notebook has extremely similar battery architecture, with the exact same "security risks".

The worst that this guy could do, given he has physical access to your computer, would be to disable your battery. If you just want to do that, a hammer will do a much better job.

I was actually working on this exact problem in grad school, but gave up when we couldn't start fires (and so did Barnaby Jack, according to Forbes -- http://blogs.forbes.com/andygreenberg/2011/07/22/apple-lapto...). What put the nail in the coffin for us was finally discovering the PTC devices on the individual cells -- they make a rather loud click and shut off if you short the cell. We also found evidence of them on cylindrical cells pulled from a PC battery.

It's not limited to Macs, but Apple's the only company I could find that released battery firmware updates. Other machines do seem to use the bq20z80, but it was easiest by far to play with battery firmware on Macs (i.e. I never got anything working on any other kind of machine).

A semi-plausible fraud threat is that you can buy old batteries off ebay that have disabled themselves in hardware due to undervoltage, re-enable them, recharge them, and resell them as "like new." They'll work for a few days and then bulge.

When you mention "battery firmware", are you referring to the settings in flash that you can change regarding safety cut-off points, etc?

Or were you actually able to make the battery's IC execute arbitrary code?

In my mind, firmware only refers to executable code. Curious though if there is a way to actually run code on those guys.

They called it a battery firmware update, but they meant the pages of settings you can change in flash. I was able to dump raw memory from the chip, but I could never figure out which generic microcontroller the battery controller had been built on top of (at least I assumed it had been built that way), so running code was a nonstarter.

Pretty similar to network card BIOS attacks, available on many PCs. You can flash the ROMs on many network cards (and other peripherals and the BIOS itself), allowing malware to run very early in the boot process.

http://it.slashdot.org/story/06/11/18/1351229/Rootkit-Could-...

I don't think it is just a hardware problem.

I thought he said he obtained the passwords from some apple update 2 years ago, which means the battery could be "updated" through some portal ,turns out such kind of hacking could be done in software level.

This guy claims he's gonna publish something that could change your MacBooks batteries' password into random strings, which means, your battery can no longer be updated, at least not by Apple. It doesn't seem to be quite a right solution for me... if someone hacked this tool, your MacBook's battery is his slave forever before anybody could crack that very password, which is probably not gonna be achieved easier than reinstall OS + hardisk + battery + etc, or buy a new MacBook.

I doubt that the battery password is needed to rewrite the battery firmware. I also doubt the battery processor is capable of a complex hash, as it is only designed to do basic reports that are allowed to take a second.

Is this problem exclusive to Apple MacBooks? Surely there are a number of products on the market with microcontrollers in a number of components that would be susceptible to similar attacks?

Sony's Playstation Portable (PSP) was hacked wide(r) open after they discovered that they could use it's "smart chip" to emulate a special Sony battery that left the firmware flashable.

"Pandora's Battery": http://www.noobz.eu/joomla/news/pandoras-battery.html http://www.krizka.net/2008/02/10/what-is-pandoras-battery/

To be more exact, a battery with ID 0xFFFF (hhm, not sure if it was 16 or 32 bit) enables service mode on older PSPs. This ID is stored on a serial EEPROM. Incidentally, you could just disconnect the data pin of the EEPROM. I don't remember if it was I2C (in which case the pin was SDA) or SPI (MISO).

So it wasn't exactly a security vulnerability, more like a failed attempt at security by obscurity.

For some insight, there was also an attack vector through the apple corded keyboards:

http://it.slashdot.org/story/09/08/01/1658258/Apple-Keyboard...

It wouldn't quite melt your keyboard or anything that cool, but this has happened with apple products in the past.

Would be a great presentation to run this and have a laptop catch fire on stage.

Reminded me how I was writing keyloggers for diskless PCs, which stored username and password compressed into several bytes available on non-volatile CMOS chip

Why, oh why, would any laptop run any code from a battery?

The laptop doesn't "run" the code, the battery runs its own code and communicates with the laptop.

As the article states to prevent, among other things, the battery to overcharge even when the laptop is turned off.

because it is a powerful coprocessor

an almost undetectable evil-maid attack.