I just recently had to replace a swelling battery on my out-of-warranty Macbook. Since the reviews for Apple's batteries were so inconsistent, I decided to go with a battery from OWC. Does anyone know if replacement batteries have this firmware issue? Do replacement parts from 3rd parties have to be 100% compatible?
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
OS X Lion Raises Bar on Security, But Battery Firmware Vulnerability Surfaces
- Thread starter MacRumors
- Start date
- Sort by reaction score
I just recently had to replace a swelling battery on my out-of-warranty Macbook. Since the reviews for Apple's batteries were so inconsistent, I decided to go with a battery from OWC. Does anyone know if replacement batteries have this firmware issue? Do replacement parts from 3rd parties have to be 100% compatible?
How soon could we see a Lion update that addresses this?
Or is it not that simple. Have considerable parts of the OS to be rewritten to password protect the EFI ( including the battery firmware)?
I find the DOS comparison somewhat strange.
I guess the (root-)user space program is in fact "just" telling the kernel to access the battery firmware, no?
I'm sure crackers are working on it as we speak, but, bypassing ASLR+ in Lion should be fairly difficult in a sandboxed application. Hopefully, Safari and every other web browser (and PDF viewer) will be sandboxed. I'm very interested in how well Apple's new security scheme works out.
You say that as if I was implying otherwise.
If you'd bothered actually following the thread : I'll give you 2/10 for trying. Your initial statement was still wrong. This is a bit more easy to exploit than taking a hammer to your Mac. This can be exploited without physical access to the machine. As such, it is important that this is looked at by Apple, which I have no doubt they will.
Why ? This kind of hardware access is the kind that was permitted and even encouraged on DOS. DOS was an "out of the way OS", it basically let you do whatever you felt like doing, as long as you knew where to write in memory.
Having access to the battery firmware in such a way is akin to those days.
In all probability, yes, through somekind of smart battery driver. The problem is, as it stands with the password known, it's like not having an intermediate layer at all. It was just a comparison, as this enables hardware-destructive type malware, something we haven't seen for quite a long time.
For Apple's sake and the sake of the product, shout outs for the person behind finding and talking about this severe security hole. How could have Apple missed this? Then again, OS X is now incredibly secure, mistakes happen.
But this needs to be addressed ASAP, or I know I'd honestly never buy an Apple laptop with this vulnerability - that's ofcourse to say, I wouldn't spend my well earned money on any other laptop if it's not a Mac, but with an issue like this, I would hold off until this is alleviated.
Seriously, since there are no viruses that exist for Mac OS X I don't see an issue with what Miller found. I do think that it will eventually be fixed by Apple. But in the mean time I don't think you have anything to worry about considering how good Lion is at security. If you are that concerned then make sure you don't let strangers use your computer.
Now if this were a Windows computer that had this issue then I could see your point a little bit more.
There might be no viruses, but there is still malware that could exploit this. Think MacDefender styled trojans that just brick your battery.
No guys, seriously. This isn't that big an issue, but it's still a an issue. Don't be quick to dismiss this.
So, in your book, if any part of the software influences the hardware, no matter which layers are in the middle (no matter if those layers include a permissions system + firmware update + protected memory kernel + drivers), that's doing something "DOS-style". Right?
All clear, then. Must be nice being able to make such comparisons. I lack the imagination.
There might be no viruses, but there is still malware that could exploit this. Think MacDefender styled trojans that just brick your battery.
No guys, seriously. This isn't that big an issue, but it's still a an issue. Don't be quick to dismiss this.
I agree that it is an issue. The MacDefender trojan could only effect the computer after the user allowed it to be installed. I am glad I know about the issue because it increases my awareness of another potential problem. Like I said, my concern is not that high because Lion is now even more secure then any of is predecessors. It won't be a case for me not to buy another Mac laptop/notebook computer.
No, in my book, if you're able to hurt the hardware by sending it unfiltered data, that's akin to DOS style hardware management. Drivers/Kernels should filter what the userspace is able to send the hardware by only presenting certain standardized APIs (it should go a step further and mask the hardware, so you don't even know what you're talking to, which is what modern OSes do).
Why are you so angered by my bringing up the DOS days ?
This is obviously not something that Apple or TI intended with their smart battery, and it will get fixed. Don't sweat it and don't lose sleep over it, flaws happen.
Charlie Miller, in his twitter feed, said full system access is required to exploit this vulnerability remotely. This would require a local exploit being linked to a remote exploit unless social engineering was used to trick the user.
Exploiting OS X to the system level is very difficult; this was true even before the release of Lion. There are no examples of malware linking local and remote exploits to infect OS X in the wild.
So, just be wary of installing apps from untrusted sources as is required to be safe online long before this vulnerability was discovered.
Password protecting the EFI will negate using a USB to exploit this with physical access by preventing booting off of a USB. Below is a guide to password protect the EFI.
http://support.apple.com/kb/HT1352
Bypassing ASLR as used in Linux and OS X is very difficult. The default browser in most Linux distros, Firefox, does not use any sandboxing and it is not being exploited in Linux because of the security mitigations alone.
Safari has that level of security mitigations as well as sandboxing. So, even if the ASLR and other security mitigations are bypassed, the attacker is stuck in the sandbox.
Browser sandboxing relies on the underlining sandbox technology of the OS. There are reports of the Chrome sandbox being bypassed in Windows 7 (see link below). But, security researchers consider the sandbox used in OS X and Linux to be a step ahead of that of Windows.
http://www.vupen.com/demos/VUPEN_Pwning_Chrome.php
P.S. In relation to the Chrome exploit link, the ASLR in OS X and Linux are a step ahead of that in Windows 7 as well.
Last edited:
Yeah, that's what I said. Way to make comparisons.
Isn't that exactly the goal of a driver? (abstract some hardware in such a way that "the user of the driver" doesn't have to deal with the details)
So, are you saying that drivers in OS X don't do that?
What do you mean with that? You mean that "modern OSes" don't let me know if I am talking to an ethernet or video card, or what?
Why are you so angered by my bringing up the DOS days ?
I'd rather say I'm amazed.
Last edited:
No, I mean that a modern OS abstracts away what Ethernet or video card you're talking to. Is it a RTL8139 ? A BCM3440 ? Who cares ? The OS will sort it out, you just go on creating sockets and writing to them and reading back them. Same for sound, video, whatever.
Everybody is aware of the fact that this research applies to all laptop batteries where the default password is left unchanged?
Given that this is a newly researched attack vector, I bet most manufacturers leave the password as default to more easily facilitate firmware updates.
I think Macs were used to present this issue to the public because nobody would have given a load if the data was presented in relation to a Windows PC machine.
Doing this to a Mac creates a more sensational headline to get the word out so the research acts as a more effective measure of public disclosure to get the issue fixed.
Given that this is a newly researched attack vector, I bet most manufacturers leave the password as default to more easily facilitate firmware updates.
I think Macs were used to present this issue to the public because nobody would have given a load if the data was presented in relation to a Windows PC machine.
Doing this to a Mac creates a more sensational headline to get the word out so the research acts as a more effective measure of public disclosure to get the issue fixed.
Last edited:
Yep. So, again, did you mean that drivers in OS X don't do exactly that? (you know, like in other "modern OSes")
*sigh*. No. Look, forget it. This isn't like the DOS days where malware could hurt your physical hardware ok ? This is just like the 2011 days where malware can hurt your physical hardware.
Forget DOS, forget any kind of analogy that I tried to make, you're right, they are plainly wrong and stupid.
Exactly, for all we know, all laptops that use the same smart battery connector and a driver capable of updating the firmware is as vulnerable. Time will tell.
Windows is a tad behind but the gap isn't that big as people make it out to be. Running arbitrary code without user intervention from the outside is very rare in Windows 7, considering the sheer marketshare Windows 7 has over OSX, the cases are very few if not very uncommon. 32 bit users can use Sandboxie, a free source app that can mitigate a lot of that risk. x64 users can also use the same app but need to enable the experimental features which allows x64 systems to benefit from sandboxie as 32 bit users do.
In a managed system, this hole is very small as most administrators often have policies in place to enable trusted sites on all browsers, running arbitrary code through a booby trapped website is very rare. The instances of this happening is very small. History shows that this issue, while it may seem serious at first, have proven to be of very low risk in reality. If this was a big issue, you can be certain that it'd be all over the web, on the news, on magazines and newspapers.
Chrome has proved superior to Safari on many occasions on many pwn2own contests and Safari has almost always been the first browser to be hacked. Chrome like any other browser isn't perfect, given enough time it too can be circumvented. Below is an older article from March but it outlines the history of Safari, Apple's update which did nothing to address the security hole. What this means to me is that while Safari might be better now, this can be said about any product including Chrome given time.
http://nbnl.globalwhelming.com/2011/03/11/chrome-remains-safe-2011-safari-hacked-5-seconds-pwn2own/
Yep, that's it again. Any time when software can access hardware in any way and do something unpleasant, it is just like the DOS days. No differences.
See? You are good!
I'd have settled for something like "absurd exaggeration", but... ok.
There are public and unpatched 0days that acheive remote code execution in Windows 7.
http://www.eeye.com/Resources/Security-Center/Research/Zero-Day-Tracker/2011/20110402
Safari was not sandboxed at the time so this is irrelevant now.
Being first to fall is irrelevant because the browsers are not pitted head to head but are hacked one at a time on a predetermined schedule.
Safari is always scheduled to be first. Most likely due to Apple not sponsoring the contest or having a bug bounty program like all of the other browser vendors that have products in the contest.
Also, pwn2own does not demonstrate exploitation to the system level.
The attacker knows the password to gain write access to the firmware for the battery. The End.
The interesting part is how the firmware can be modified to perform various types of malicious outcomes.
Last edited:
This sounds like an operation for an IT or computer tech guy. I guess I'd rather keep my hands off my computer's firmware.
I'm very careful about downloading. I never download through a link, but always go to to originator site.
There's a lot more than what that website points out, however like I said earlier, the severity of the issue is based the frequency of the likeliness for it to happen out in the real world. Again I've heard of no such issue outside of specific environments created to make the issue surface. If I continue to use my Win7 machine, the likeliness of those issues to put me at critical risk is lessened due to everyday (no special) means that's already in place. Firewalls mitigate some of the risks, type of antithreat software in place, if you're on a managed system, whatever permission/policies in place including firewall restrictions takes a lot of those risks away.
It's like if you went outside while it was raining, you could possibly die from a stray lightning bolt hitting and killing you... or at the very least severely injuring you, however what's the likeliness of this to happen, however does that mean everyone should not go outside while it's raining? Proper risk assessments don't just include severity, but also incorporates the frequency (probability) of such a issue to happen. Control methods (patches, updates, etc.) are then deployed in accordance with the resulting risk level.
A proper risk management system incorporates the residual risk(s) after assessing the severity and probability (likeliness) together. If the residual risk was that severe, I'm almost certain a solution would've been made available.
Even sandboxing isn't perfect, like I mentioned earlier it's only a matter of time, not just limited to Safari. Chrome operates in a sandboxed environment and it was circumvented, just because Safari's a product of Apple does not magically make it immune to future hack attempts. What this illustrates is while many people like to think Apple's taking the lead in many things, the browser wars clearly show that it was trailing behind and only recently came up to speed.
Its relevancy is actually determined by the total demographic of users of the current Safari versus users of the older, still vulnerable version. Whether users are unable, unwilling, unaware of upgrading to the latest version is a real factor, the issue remains that the risks aren't eliminated just because a new version is out. Same for when I see posts about "Windows"... while Windows 7 is a vast improvement over XP in almost every way, I can't totally discount XP-related issues because it's still officially supported and demographically there are a lot of XP users today.
Actually being the first to fall is quite relevant, esp if it only took between 5 to 10 seconds to crack the browser where users (contestants) were forced to get into the system remotely (through the WAN) which is a lot more difficult than trying to do it within the LAN. If you recall, Apple made bold remarks about how secure and advanced Safari was over all the other browsers and all it took was 5-10 seconds from "the outside" to bust through it. Other well known browsers took much longer to circumvent, Chrome either prevailed or took the longest to get through.
While browsers aren't "pitted" against each other, in an indirect sense they are. Each company strives to continue their improvements in order to stay with the latest demands and security risks. Whatever advantage 1 company's browser has is usually only a temporary lead until the others catch up and/or surpasses it. Each product collectively pushes other products to improve.
The battery issue I feel is a very small risk. The article is only 1 dimensional in such that it only addresses the severity of the risk, not the likeliness or probability of it actually happening in the world. It would be like saying that a desktop user addresses a huge risk to my machine just because I use a laptop and carry it around from place to place... so if I drop it I could destroy my machine. While there's no question about the severity of what could happen "if" I dropped my machine, in reality I have never dropped any laptop before, I have "controls" in place to mitigate that issue down to nearly inconsequential.
Security professionals would like everyone to live a very paranoid life, to them just being connected to the internet is a huge risk on security in general, but that doesn't mean you should unplug your computer and use it 1980's style, limited to local software and resources. Technically some keyboards and mice have firmware as well, but you don't see huge security posts about how it can brick your machine.
So yes, it CAN happen, but I believe the likeliness of any of the circumstances for any of what's posted above is much less than what the article suggests.
Last edited:
Software firewalls are ineffective against malware that corrupts processes in memory.
http://www.symantec.com/connect/articles/software-firewalls-made-straw-part-1-2
Bypassing anti-virus software is not that difficult.
http://www.exploit-db.com/download_pdf/17066
Discretionary access control (DAC = permissions) is easily bypassed in Windows 7 and this has been done in the wild (see #1 in the link).
https://forums.macrumors.com/posts/13013889/
Drive-by-downloads still seem to be an issue.
http://threatpost.com/en_us/blogs/drive-downloads-still-running-wild-111710
Windows sandboxing system is not as good as that in OS X and Linux. Chrome's sandbox in Windows is based on Windows sandbox system.
That doesn't mean that it is impossible. But, browser exploits haven't occurred in OS X in the wild prior to Safari being sandboxed because OS X offers less vectors to make malware profitable once past the browser.
It is not relevant.
If a browser is going to fall to an exploit, whether it takes 5 or 30 seconds makes no difference. From what I remember, IE fell just as quickly. Both exploits were referred to being fairly immediate.
Both Safari (2 researchers 3 weeks) and IE (1 researcher 6 weeks) took six weeks in working hours to find and write the exploit. This is what is important because it determines the cost to the hacker in developing the exploit.
You have to remember that any presentation of the results of the contest will be biased in favour of those that sponsor the contest or provide funding to researchers via other means. Apple does not provide much if any funding or revenue to the security research industry.
Not much can be done in OS X using automated mass malware after the exploit is through the browser. Sensitive data entry in protected by user space security mechanisms which in turn are protected by DAC. DAC is much more reliable in OS X (see #1 in link below). Protected storage is actually protected in OS X (see #8 in link below).
https://forums.macrumors.com/posts/13013889/
This is why malware targeting OS X always relies solely on social engineering.
Last edited:
I don't really see this as anything major...
You need to be SU... that would first require social engineering (easy), but I was always under the impression that if you wanted to do battery firmware modifications you would have to do it on-location, not remote.
Anyone knowledgeable care to elaborate?
You need to be SU... that would first require social engineering (easy), but I was always under the impression that if you wanted to do battery firmware modifications you would have to do it on-location, not remote.
Anyone knowledgeable care to elaborate?