Apple left default passwords in batteries, making them vulnerable to hacks, explosion

smart battery system schematic

Are our computers too smart for our own good? That's the question I'm asking myself after reading Charlie Miller's "Battery Firmware Hacking" paper. Miller showed how you can write programs to render an expensive notebook battery worthless. You might even be able to blow one up.

How could this be? What design error in the system made it possible? None. Miller wrote programs based on published documentation for chips conforming to a popular standard. But there is one key mistake by Apple that makes the whole thing a lot worse.

The standard is the Smart Battery Specification. Consumer electronics batteries, especially on complex devices like computers, are complex devices themselves. They interface with the host system to allow for fine control of the power in the system. It turns out that if a program has the correct code to do so, it can query the device for its status and command it, as well as the charger. It can also command it to do things which cause damage to the battery, possibly damaging it, possibly making the battery unusable. In fact, Miller says it's easy to ruin a battery by misprogramming it. But even though the SBS goes to great lengths to preserve safety, a program in control of the system might even be able to overheat the battery and cause a fire.

Charlie Miller is one of the best-known characters in the vulnerability research business. For years he has been famous as the only person to do serious research on Apple products, especially on Macs. He has a shelf full of Pwnie awards to show how good he is at it. @0xcharlie, as he's known on Twitter, will be speaking next week at the BlackHat conference in Las Vegas, presenting the paper I read (at which point it will be fully available to the public), but he has no Pwnie nominations this year. He's probably been too busy with his new job as Principal Research Consultant for Accuvant LABS, the security assessment and research division of Accuvant.

Being a Mac guy, Miller worked with Macs for this testing, but it's reasonable to presume that the problems might exist on other notebooks as well. SBS is a popular specification. The attacker would need to do Windows programming -- there are plenty of references on power management in Windows—or it may be necessary to talk directly to the devices through a device driver interface, but it certainly can be done. He doesn't have a complete list of which Macs are vulnerable, but every one he tested was, one going back to 2007.

But it can't necessarily be done on any SBS-compliant system because they didn't necessarily make the mistake that Apple did: They used the default passwords for accessing and programming the battery using the Texas Instruments power management chipset. Out of the box, batteries in these systems are "sealed" to prevent software from modifying their settings. To unseal them you need to authenticate to them using a password. Apple used the default TI passwords for unsealing the battery and entering "full access mode". Miller was able to look these up in the Texas Instruments docs and use them.

Changing the passwords in an update is probably futile for Apple because updates can be reverse-engineered. All they can do is to protect new systems from here on. Whether other notebook manufacturers make the same mistake is not clear, but we'll probably find out soon.

In the process of this testing, Miller "bricked" 7 Mac batteries. See the battery graveyard below:

If you want to do so, you can actually reprogram the battery firmware. It's important to point out that an attacker would need to be able to run privileged code on the system, possibly to run it as the root user. This is hard to do without some other compromise in place and would be very hard, if at all possible, in a "drive-by" fashion as on a web page. But, combined with social engineering to get code on the system and, perhaps, a privilege escalation vulnerability, it could be done.

It's hard enough designing a power management spec that maintains safety under normal specifications. Engineers must be frustrated to have to consider the possibility of malicious power management code, but then here we are. It's possible and it's not too crazy to imagine it being done. And now that it's well-known and documented it's up to the battery, chipset and computer companies to take reasonable steps to account for it. None of that can help the users of existing vulnerable systems.

This is what happens with complexity. To make our batteries smart and efficient we need to make them complex. When you make them complex you make them more vulnerable to attack. When you don't take care to protect these vulnerable systems, users are at risk. Unfortunately, complexity is all around us and growing.

Larry Seltzer is a freelance writer and consultant, dealing mostly with security matters. He has written recently for Infoworld, eWEEK, Dr. Dobb's Journal, and is a Contributing Editor at PC Magazine and author of their Security Watch blog. He has also written for Symantec Authentication (formerly VeriSign) and Lumension's Intelligent Whitelisting site.

© 1998-2020 BetaNews, Inc. All Rights Reserved. Privacy Policy - Cookie Policy.