Macs Vulnerable To Userland Injected EFI Rootkits

Bismillah writes that a new vulnerability in recent Macs — and potentially older ones — can be used to plant code such as rootkits into areas of EFI memory that shouldn't be writeable, but become unlocked after the computer wakes up from sleep mode. The article explains that [The vulnerability] appears to be due to a bug in Apple's sleep-mode energy conservation implementation that can leave areas of memory in the extensible firmware interface (EFI) (which provides low-level hardware control and access) writeable from user accounts on the computer. Memory areas are normally locked as read-only to protect them. However, putting some late-model Macs to sleep for around 20 seconds and then waking them up unlocks the EFI memory for writing.

Comments

Still needs another vulnerability

[cerberusss]

FTFA:

The researcher who discovered the flaw, Pedro Vilaça, said the vulnerability can be used to (some examples) that is invisible to the operating system in the writeable flash memory

So to summarize: as a user, you can sometimes write to EFI memory.

That's currently all there is to it. There's no rootkit, there's no malware, etc. Just this space where you can hide and survive an OS wipe and reinstall.

I'm sure some will come up with a payload that uses this space to hide itself, no doubt about it. But currently, this is all there is to it.

Re:Still needs another vulnerability

[Anonymous Coward]

Oh, I know how to solve this one. There's a bug in the EFI capsule update mechanism that allows to install unsigned firmware updates if you have root.

Now combine it with this bug, and you can corrupt an EFI update initiated by root from an unprivileged account. Essentially, wait for the next EFI update and you get arbitrary code execution from Ring 3, userland, to Ring -3, the firmware.

Re:Still needs another vulnerability

[Anonymous Coward]

It's enough to make such a thing. Just lurk until it becomes writable, then make good use of it. Much simpler than stealing keys from the next VM over by cache-timing attacks, and we've seen those to be viable. So insisting on proof for what ought to be obvious is maybe a bit facetious.

This thing is also more indication that EFI actually makes peecees more insecure because there's another layer of software running with even more privileges than the OS itself, and it's closed-source firmware. Crappy firmware. Expect more holes to be found. Brought to you by the kings of gifts that keep on giving. And no, I don't mean just apple, far from it.

Re:Still needs another vulnerability

[Anonymous Coward]

Just this space where you can hide and survive an OS wipe and reinstall.
I'm sure some will come up with a payload that uses this space to hide itself, no doubt about it. But currently, this is all there is to it.

Sure. Same way there was no exploit for heartbleed.
It was just a way to maybe get some memory. All there was to it.

Re:Still needs another vulnerability

[Viol8]

Blame Intel with their idiotic system management mode. The person who thought that was a good idea should have been fired on the spot instead of the damn thing actually being implemented since the 386.

Re:Still needs another vulnerability

[Anonymous Coward]

FTFA: The researcher who discovered the flaw, Pedro VilaÃa, said the vulnerability can be used to (some examples) that is invisible to the operating system in the writeable flash memory

So to summarize: as a user, you can sometimes write to EFI memory. That's currently all there is to it. There's no rootkit, there's no malware, etc. Just this space where you can hide and survive an OS wipe and reinstall. I'm sure some will come up with a payload that uses this space to hide itself, no doubt about it. But currently, this is all there is to it.

This *is* the vulnerability. The EFI loads the OS. If you can overwrite the EFI, game over. The OS will do whatever the new rootkit-EFI that loaded it tells it to do.

Re:Still needs another vulnerability

[Dog-Cow]

EFI does not run with more privileges than the OS.

Re:Still needs another vulnerability

[Anonymous Coward]

In other words, pay no attention to that man behind the curtain. Nothing to see here, move along, citizen.

Re:Still needs another vulnerability

[benjymouse]

So to summarize: as a user, you can sometimes write to EFI memory.

That's currently all there is to it. There's no rootkit, there's no malware, etc. Just this space where you can hide and survive an OS wipe and reinstall.

Yes - it is a vulnerability for which there is no exploit published (yet).

This vulnerability is serious, as it allows an attacker to permanently infect the Mac *firmware* and gain control each time the Mac is booted - even if you nuke and reinstall OS X.

You may try to dismiss this as "still needs another vulnerability". Another vulnerability or even a social engineering attack, evil maid attack will all suffice. This one can be used to take permanent, undetected residence on successfully exploited macs.

That's bad in my book

Re:Still needs another vulnerability

[fuzzyfuzzyfungus]

Less of an issue among people/organizations who exclusively buy new, from manufacturer or authorized retailer; but (at least on the PC side, I don't deal much with mac procurement), refurbished off-lease units are an enormous market. Very, very, popular with organizations that can't afford to ride the latest-and-greatest. It's not glamorous (something like the Optiplex 780 is nothing to write home about; but if you need a few computer labs or a cube farm on a tight budget, the fact that you can get units with an adequate 3rd party warranty, no DOA, 4GB of RAM, and an adequately punchy CPU for ~$150, sometimes a little less, each, is pretty compelling.

"Previous owner" isn't a scary vulnerability for exploits that live at the OS level; all the refurb stuff typically gets wiped once by the refurb house during their testing process, and re-imaged when it reaches the customer; but it is damn scary for firmware-level exploits. Especially motherboard firmware(HDD firmware exploits are scary; but taking out the HDD and shredding it, then replacing it with another low-capacity-everything-is-on-the-network-anyway boot disk is at least cheap); which compromises the system at a scary-deep level, and also compromises the component that makes up most of the value of the computer.

Without a good OS-level vector, preferably with a nice internet infection capability, it isn't a good candidate for a pandemic; but if this sort of firmware fuckery makes the used market about as reliable as buying street drugs, it will have a major impact.

Re:Still needs another vulnerability

[Lumpy]

"Just this space where you can hide and survive an OS wipe and reinstall." IF the user only put the unit to sleep and then woke it. Simply turning off the unit for a short time before OS wipe and reinstall defeats this potential hole.

I am betting that Windows, BSD, and Linux have a similar vulnerability lurking.

Re:Still needs another vulnerability

[jabuzz]

I think you will find that SMM debuted in the 386SL and continued in the 486SL begore becoming mainstream in the Pentium.

Those processor codes should give you a clue as to what it's original purpose was and why it came about.

Re:Still needs another vulnerability

[Anonymous Coward]

And we're still left with this nasty pain-in-the-butt EFI and UEFI setup on machines. It's just more of that damn security theater.

Re:Still needs another vulnerability

[alex67500]

you mean like the downward facing call-stack which has provided so many buffer overflows over the years? seems to me like they've been breeding fast inside Intel...
(pun intended)

Re:Still needs another vulnerability

[alex67500]

still ring-0. quite a big deal...

Re:Still needs another vulnerability

[Anonymous Coward]

You don't seem to have a good grasp of how this vulnerability could be exploited -- and it has nothing to do with used macs.

Re:Still needs another vulnerability

[sjames]

Actually, it does. What happens if someone resells a mac w/ an EFI hack installed?

Re:Still needs another vulnerability

[Anonymous Coward]

Now this comment is actually insightful. Not sure how the parent post made it.

Re:Still needs another vulnerability

[Anonymous Coward]

This is flash memory, in other words, persistent. Turning the computer off isn't going to help.

Re: Still needs another vulnerability

[Anonymous Coward]

I was intending(apologies if I was unclear) to respond to the grandparent post's 'there is no malware, there is no root kit' and TFA's note that the exploit requires some privileges on the system to use.

There is a Big used/refurb market, and it largely operates on the faith that the previous owner couldn't fuck up anything that a disk wipe and replacement of any damaged mechanical parts wouldn't fix. Persistent firmware implants blow that assumption out the window.

Re:Still needs another vulnerability

[Anonymous Coward]

But currently, this is all there is to it.

That you know of...

Re:Still needs another vulnerability

[mjwx]

So to summarize: as a user, you can sometimes write to EFI memory.

That's currently all there is to it. There's no rootkit, there's no malware, etc. Just this space where you can hide and survive an OS wipe and reinstall.

Yes - it is a vulnerability for which there is no exploit published (yet).

This vulnerability is serious, as it allows an attacker to permanently infect the Mac *firmware* and gain control each time the Mac is booted - even if you nuke and reinstall OS X.

You may try to dismiss this as "still needs another vulnerability". Another vulnerability or even a social engineering attack, evil maid attack will all suffice. This one can be used to take permanent, undetected residence on successfully exploited macs.

That's bad in my book

Hey, dont try to use logic and reason here.

Re:Still needs another vulnerability

[mjwx]

"Just this space where you can hide and survive an OS wipe and reinstall." IF the user only put the unit to sleep and then woke it. Simply turning off the unit for a short time before OS wipe and reinstall defeats this potential hole.

I am betting that Windows, BSD, and Linux have a similar vulnerability lurking.

IF they're on the same hardware. This is a vulnerability with the EFI on Apple computers. Because the hardware and firmware are different the same vulnerability is likely not exist with the EFI on IBM servers.

Also you're wrong about turning it off for a short time. This is basically the same as the flaws that lead to the old BIOS viruses. As malware can hide in the EFI it doesn't care what you do with the OS as the EFI is completely independent of it.

Re:Still needs another vulnerability

[Viol8]

You don't need a special processor mode to do power management FFS.

Re:Still needs another vulnerability

[fuzzyfuzzyfungus]

Exactly. When it's your own gear, you only have to worry about vulnerabilities that can be exploited despite whatever measures you have in place.

If there's potentially malware that embeds itself hard enough to resist a disk wipe, or even replacement, you have to worry about the prior owner's security, incompetence, potential malice, etc. And that's even if you aren't cool enough to have the NSA 'implant' teams intercepting your mail.

Given the size of the secondary market for things with firmware in them(ie. basically all computer parts more sophisticated than cables; and even some of the cables these days), I'm a bit surprised that this hasn't already become an epic clusterfuck. Especially with scary little things like LOM modules, which are full computers, most commonly with independent NICs, that you graft right into the brainstem of your servers. Flooding the market with poisoned LOM cards/modules seems like the sort of thing that might even be worth it for a commercially minded criminal, much less a nation state looking for juicy secrets.

Re:Still needs another vulnerability

[doccus]

That's bad in my book

Well, i'd say.. If it can't be erased or written over, nothing short of replacing the peocessor would save the MAc. But shouldnb't you be able to overwrite any malkware? if it can be accessed once, then surely again..

Re:Still needs another vulnerability

[Anonymous Coward]

Dear ignormaus, if you have no idea of the difference between firmware, the CPU, the operating system, and userspace, please do not chime in.

Re:Still needs another vulnerability

[sjames]

The LOMs are a real concern. Some more than others. The ones that are just bridged into the ethernet and have a serial prot connection (possibly connection to the video card) are not TOO risky as long as they are kept off of the public internet (sadly, many aren't isolated), but some also have JTAG connections to the main system. They can do absolutely anything they want to the server including hot patching the OS..

recent = made before mid 2014

[fpoling]

Vilaça believes Apple is aware of the issue - his testing shows the flaw is not found in the firmware of Macs made after mid 2014.

Re:recent = made before mid 2014

[drinkypoo]

VilaÃa believes Apple is aware of the issue - his testing shows the flaw is not found in the firmware of Macs made after mid 2014

How kind of Apple to publish a security advisory on the issue, like a reputable and scrupulous vendor would have done.

Re:recent = made before mid 2014

[fpoling]

It could be just that they accidentally fixed the bug with other updates or just had not realized that what was they were fixing was a security vulnerability. In any case it is sad that a company with so much in cache reserves could not afford to get it right the first time.

Re:recent = made before mid 2014

[drinkypoo]

It could be just that they accidentally fixed the bug with other updates or just had not realized that what was they were fixing was a security vulnerability.

That's true, I shouldn't ascribe to malicious incompetence what may be due to simple incompetence.

Re:recent = made before mid 2014

[Anubis IV]

Vilaça believes Apple is aware of the issue - his testing shows the flaw is not found in the firmware of Macs made after mid 2014

How kind of Apple to publish a security advisory on the issue, like a reputable and scrupulous vendor would have done.

Note the sentence in the article that wasn't quoted by the previous poster but which immediately followed it...

He did not disclose the flaw to Apple.

So, this is a flaw that Apple has not been notified about, which only exists in older hardware, and which is fiddly enough that the researcher can't explain why it's being caused, but does know that it needs to be targeted for specific machines. It's entirely likely that because this issue must be targeted at specific versions of firmware for each model that whatever fiddly bits were making it possible in the first place were simply accidentally modified sufficiently enough to make it impossible once again.

I'll chalk this one up to incompetence, rather than malice.

Re:recent = made before mid 2014

[Anonymous Coward]

.... it is sad that a company with so much in cache reserves could not afford to get it right the first time.

I see what you did there.

Re:recent = made before mid 2014

[Anonymous Coward]

A company using Intel CPUs does not have cache reserves. AMD has always been king of cache.

Will anyone exploit it?

[Anonymous Coward]

With Mac's making up about 6% or so of PC market. Does anyone care about doing attacks on OS X or Mac's? In fact, it does seem the direction towards attacks made outside of singular device hardware is becoming more popular. Attacking routers, severs, even cloud based systems. Or direct attacks against certain systems that guarantee financial gain. Such as personal information, or other private information that can be sold. Maybe the NSA still wants to rootlet your Mac. But most hackers want monetary gains not small potato's these days. The stuff Mac users fall for are more ransomware and fake click jacking stuff. This rootkit potential is just that. Something Apple will most likely fix but is also less likely to be exploited.

Re:Will anyone exploit it?

[fuzzyfuzzyfungus]

If I'm just harvesting nodes for my botnet, macs are pretty lousy targets, no more capable than PCs and substantially more obscure.

If I'm attacking systems for the data on them, or to MiTM/trojan/keylog the users of the systems; grab banking credentials and the like; mac users are a conveniently self-selected group of people atypically worth harvesting. Sure, there are a bunch of underemployed baristas with degrees in Individuality using the macbook pro that mommy and daddy bought them to watch movies in their dorm room; but as a whole, thanks to the higher prices, users of OSX devices skew upmarket pretty substantially(iOS devices have some of the same effect; but much less, since at least an iPhone 5c or the like is probably available as the 'free'-with-usurious-contract model on most telcos).

If you are attempting a corporate/institutional intrusion, macs vary in value: they are way, way, less common, frequently absent entirely; but where they are present, their minority status often means very limited integration into the enterprise's legion of 'security' products, IDSes, and everything else that the Windows users complain is causing logins to take 30 minutes. This makes them handy 'beachhead' systems, especially if they are loaded up with Office, Adobe Malware Runtime, and similar stuff that may well have cross-platform or partially shared libraries of vulnerabilities; but much reduced vigilance on OSX clients.

Re:Will anyone exploit it?

[jo_ham]

Targeting OS X is tempting because of 99% of all Mac users *knows* that "Macs can't get infected" (the Apple salespeople told them so), and therefore they don't have any kind of antivirus installed.

At work, I daily deal with Mac-users who gets their mailaccounts hijacked because of infections. It takes roughly 10-20 minutes to convince them to download and run Avast or something like that, but it's worth the "oh....".

Out if interest, what "infections"? Do you have any examples. That's clearly a big issue if you're dealing with it daily. What infections are we talking about here?

Not that I'm doubting your story or anything.

(NECESSARY DISCLAIMER: I AM NOT CLAIMING THAT OS X CANNOT GET INFECTIONS)

Re:Will anyone exploit it?

[fpoling]

Macs are popular with developers (on some software conferences over 50% of laptops could be Macs) and getting control of those machines opens many more possibilities than just threatening to delete or share personal pictures.

Re:Will anyone exploit it?

[Lumpy]

I see your education on macs and OSX is so horribly outdated that your comment is essentially useless. Many do worry about it this is why several virus scanner companies are making products for OSX. Hell you can even get a free Avast for OSX. They would not even bothered if people were not asking for it.

Re:Will anyone exploit it?

[Dunkirk]

Note that "people" are probably CIO's of Fortune 500's.

As an engineer who was doing programming and systems work in engineering, I evangelized Linux for a decade and a half at a Fortune 250. When someone in IT finally took a look at it, they, of course, demanded that it have a virus scanner. (To be fair, this was near one of the really big Windows outbreaks.) One of the AV companies had actually released a Linux version, so I just calmly told him about it, and stroked his notion that Linux was actually ready for the desktop, even though I thought the whole idea a complete waste of time. In my opinion, cleaning up whatever MIGHT have been caused by a Linux infection would never have been worth the traded performance and administrative overhead of installing it and keeping it updated.

Seems to me that this scenario might be playing out again, as OS X is actually a viable corporate desktop now. Again, I don't think the level of risk warrants the level of cost, but that's not my call. Having a "corporatized" AV (like the Symantec monstrosity that frequently stalls this high-end Dell mobile workstation) is a checkbox that would open the door to corporate deployments of Macs.

Re:Will anyone exploit it?

[Anonymous Coward]

The BBC love Macs

Re:Will anyone exploit it?

[ColdWetDog]

AIDS, Hepatitis, GC, Herpes - Mac users can get all sorts of infections. It's really scary sometimes.

Re: Will anyone exploit it?

[jazzdude00021]

If I had mod points, you'd have em. Institutional policy is the prime reason that AV exists for Macs. AV companies saw Macs coming into the workplace at greater rates due to the proliferation of iDevices and the frustration of using Windows 8 and decided a Mac version of their software might be profitable. No other reason than that. The primary marketing tactic from those companies was to protect your inbox so you didn't accidentally forward a PC virus along. In 8 years of Mac ownership, my AV (yes, I'm a Mac owner with AV on my system) has detected one PUP in an attachment auto-downloaded thru my mail client, and the exploit was for Win32. Job done. AV works and serves its purpose.

Now, before the torches come out and the chants of "Fanboy!" start, I am sure someone out there somewhere has a Mac virus that could spread and wreak havoc. The darker parts of the Internet know about security exploits long before most /.-ers will. That said, I don't think this exploit will turn into a pandemic precisely because of the fact that >10% of computers are Macs. Hacking is a business, granted it is a criminal business, but business economics still apply, and writing an exploit for 10% is far less profitable than writing for 90% of users. Even if that 10% are totally security unaware.

Re:Will anyone exploit it?

[Anonymous Coward]

Hahaha OS X... enterprise ready??? HAHAHAHAHAHAHAHA

What IT world do you live in. Managing hundreds or thousands of Macs in the workplace is an absolutely nightmare. Poor quality 'enterprise' tools, non-existent policy controls, horrible update options... a total PITA. Apple doesn't care about business/enterprise sales.

Re:Will anyone exploit it?

[macs4all]

At work, I daily deal with Mac-users who gets their mailaccounts hijacked because of infections. It takes roughly 10-20 minutes to convince them to download and run Avast or something like that, but it's worth the "oh....".

How are there mail accounts being hijacked? Because, seriously, I have never heard of a problem with that using OS X Mail.app.

I have been using Macs since they were Lisas, and OS X since the DP4 Public Beta, and have never heard of a Mac having a "hijacked" email,

Nothing stops someone from reselling your email address into slavery; but seriously, I have never heard of Macs being unwitting members in a Botnet, etc.

So, what exactly do you mean by "mailaccounts [sic] hijacked"? Citation, please.

Re:Will anyone exploit it?

[macs4all]

I see your education on macs and OSX is so horribly outdated that your comment is essentially useless. Many do worry about it this is why several virus scanner companies are making products for OSX. Hell you can even get a free Avast for OSX. They would not even bothered if people were not asking for it.

99.99999999999999999999999999999999% of those people are ex-Windows "Switchers"; who simply CANNOT believe that a computer system doesn't need sixteen-factors of malware protection.

Sorry. The ONLY reason why those companies are providing those AV products is to serve the perenially-paranoid.

I'm not saying that Macs CANNOT get viruses; but in over a DECADE of OS X, they just haven't. Period.

Re:Will anyone exploit it?

[macs4all]

Hahaha OS X... enterprise ready??? HAHAHAHAHAHAHAHA

What IT world do you live in. Managing hundreds or thousands of Macs in the workplace is an absolutely nightmare. Poor quality 'enterprise' tools, non-existent policy controls, horrible update options... a total PITA. Apple doesn't care about business/enterprise sales.

And yet, they just keep growing and growing; and the number of Macs in the workplace keeps growing and growing.

So, you had better adjust your thinking buddy-o; before you find yourself on the outside, looking in...

Re:Will anyone exploit it?

[danomac]

Out if interest, what "infections"? Do you have any examples.

Keep in mind malware = virus for most computer users.

I myself have cleaned two MacBooks of malware in the last six months. We don't use them here at work, but I had a neighbour bring over their two MacBooks because they had a "virus".

It turns out their children (adult children!) were going to free TV sites and the like and had their web browsers taken over (yes, including Safari. They had two browsers on these laptops, Chrome and Safari). Both machines were unable to connect to the internet. It also slowed the entire machine to a crawl, I had to wait almost 10 minutes for a terminal to open. This is not a virus per-se, as it only infected the local user accounts, and it fucked up both browsers so badly that browsing the internet was impossible, I couldn't even get it to load Google's search page. netstat showed that there were serveral processes running trying to talk to the internet. Now fixing these was not that difficult, as it only "infected" the local profiles.

However, they were the ones who brought it to me and said it was virus-infected. I guess they had a PC laptop before the MacBook, and only bought the MacBook because they were told it can't get viruses. Both told me when their MacBooks break down they won't pay the premium to get another Mac laptop.

Re:Will anyone exploit it?

[KGIII]

They will probably get an iPad and think that is safe... Well, they will if they are anything like my Apple loving chess-playing friend. I am his tech support which sucks as I have only owned a MBP once since the ][e days. Search engines and it being a form of UNIX are all that make me look good, even then it sometimes takes a day or two for turnaround.

Re:Will anyone exploit it?

[KGIII]

I do not vouch for the validity nor do I know what your definition is... I did have this in my favorites though:

http://securitywatch.pcmag.com...

You can say that those are infected applications but that is splitting hairs as far as I am concerned. Computers do not get viruses. People do. Security is a process and not an application - this is true for all computers.

Time for the BIOS to be EEPROM again?

[Viol8]

That way it can't be overwritten by software. Or at least require an internal jumper to be set before any writes can happen. Any user updating their BIOS would be fairly experienced so taking the lid off an setting a jumper wouldn't be a problem for them and people who arn't technical could just take it to a store.

Re:Time for the BIOS to be EEPROM again?

[Registered Coward v2]

That way it can't be overwritten by software. Or at least require an internal jumper to be set before any writes can happen. Any user updating their BIOS would be fairly experienced so taking the lid off an setting a jumper wouldn't be a problem for them and people who arn't technical could just take it to a store.

Or, ship each Mac with an encrypted dongle that must be unlocked to do a firmware upgrade. You could even print the key on the dongle so you wouldn't worry about losing the key; if yo lose the dongle then still allow an authorized service center to do firmware upgrades. Of course, this my be a solution in search of a problem.

Re:Time for the BIOS to be EEPROM again?

[jones_supa]

It's interesting that a lot of effort has been put into things like SecureBoot, but there is still a plethora of devices in a PC which are ready to accept new (potentially malicious) firmware at any given point in time.

Re:Time for the BIOS to be EEPROM again?

[Anonymous Coward]

I think I like the jumper on the system board method a lot better than juggling keys. Reasons why left as an exercise.

Re:Time for the BIOS to be EEPROM again?

[Anonymous Coward]

Or you could take the nefarious route and infect your own Mac with an EFI root kit. Call Apple and tell them you have some problem with the Mac. They'll tell you to bring it to the nearest Apple Store for diagnostics.

Apple to Mothership. Now where did I see this played out before?...

 

Re:Time for the BIOS to be EEPROM again?

[swb]

Some of this seem to be blameable on hardware makers who once made firmware updates hard -- you had to set a jumper on the motherboard. Then they got rid of that part, but you couldn't flash it from the dominant GUI operating system and had to boot from a DOS disk. Then you didn't even have to do that and could flash any firmware on the system from the GUI.

Now it's too easy. It would seem to make more sense to require the system to be booted to a firmware update mode, simple and reliable enough to be placed in ROM where it could always be trusted but sophisticated enough to have both enough user interface to choose a storage device for firmware and enough intelligence to recognize which files were firmware for which devices so that there wasn't any real risk of bricking the device by flashing the wrong firmware.

Server makers could sort of bypass some of this via remote management capabilities most servers have built in so they wouldn't need to do it via GUI or special boot modes.

Re:Time for the BIOS to be EEPROM again?

[geekmux]

That way it can't be overwritten by software. Or at least require an internal jumper to be set before any writes can happen. Any user updating their BIOS would be fairly experienced so taking the lid off an setting a jumper wouldn't be a problem for them and people who arn't technical could just take it to a store.

In the day and age where the tablet device is being pushed as the desktop replacement, and a laptop can be outfitted to be on par with desktop performance, it's becoming harder and harder to find this "lid" you speak of...

Re:Time for the BIOS to be EEPROM again?

[geekmux]

It's interesting that a lot of effort has been put into things like SecureBoot, but there is still a plethora of devices in a PC which are ready to accept new (potentially malicious) firmware at any given point in time.

Well, at least now you have an idea of just how bad IoT deployment is going to get.

Re:Time for the BIOS to be EEPROM again?

[Culture20]

I think I like the jumper on the system board method a lot better than juggling keys. Reasons why left as an exercise.

I like the extra security of forcing someone to open the (physically locked?) machine as much as the next guy, but weigh that against the nuisance of having to do it yourself on all the Macs you own if you need to flash their EFIs for some reason. If they're iMacs, the front glass is taped to the case, and you'll need certified Apple(TM) brand replacement double sided tape to seal it back up again since the tape is one-use. Opening just one iMac is a thirty minute job if you know what you're doing.

Re:Time for the BIOS to be EEPROM again?

[fuzzyfuzzyfungus]

Given that laptops(especially Apple's) are an increasingly heroic enterprise to open; 'internal jumper' probably isn't happening; but you might be able to get away with some other 'physical presence verification' mechanism that exploits buttons that the system already possesses(similar to the way that Chromebooks killed physical dev-mode switches, because OEMs didn't like the added cost, so now it's some multi-key combo during boot).

Not as good as a true hardware write protect(in theory, a suitably capable attack might be able to emulate USB HID or ACPI button events); but much more likely to actually happen than anything that requires cracking the case or increasing the BoM.

Re:Time for the BIOS to be EEPROM again?

[AmiMoJo]

No need for such an elaborate and potentially annoying scheme (most people will lose those dongles). Just make it so that only the firmware can update itself, and it only accepts cryptographically signed updates.

You can get memory ICs that can be locked against reading and writing until power cycled. The firmware does what it needs to do, locks the whole firmware against writing early in the boot process, and maybe locks any sensitive data (like crypto keys) against reading as well. If software wants to update the firmware it writes a new image into a separate writeable memory area and then asks the power management controller to do a power cycle. The firmware picks the image up and verifies its crypto signature before applying the update.

Apple did try to do something like that with its battery firmware, but screwed up by including the private key in the updater application. If you can avoid such obviously stupidity then this scheme is adequately secure, low cost and reliable for most consumer purposes.

Re:Time for the BIOS to be EEPROM again?

[Anonymous Coward]

Secure Boot assumes trusted firmware

Re:Time for the BIOS to be EEPROM again?

[sribe]

That way it can't be overwritten by software. Or at least require an internal jumper to be set before any writes can happen. Any user updating their BIOS would be fairly experienced so taking the lid off an setting a jumper wouldn't be a problem for them and people who arn't technical could just take it to a store.

Oh yeah, great. So when there's a critical flaw in there which actually needs to be fixed, and IT in a company is supporting dozens, or hundreds, or maybe even thousands of machines. Yeah, great.

Re:Time for the BIOS to be EEPROM again?

[Anonymous Coward]

So what do you envision as the alternative? Those keys are bound to be manufacturer keys that risk going AWOL or never getting issued in the first place, and then you not only need to open the case, you need to find the JTAG on-board header, if any, and reset the firmware through that, possibly with an open source alternative because the original also turns out to be unobtanium. Where, for example, licensing stickers on the case might be a not-entirely-horrible idea for software since you need a valid key for that class of machine, for keys just swapping out the panels between two machines that happen to be in the shop at the same time might turn out deadly because you now need precisely that key or nothing will work. So I say keys are more likely to be more finnicky and even outright disablers of the whole second hand market thing. Which is of course exactly what manufacturers would like at first glance, but no customer, not even a first hand customer, should because it depresses resale value to nil.

Re: Time for the BIOS to be EEPROM again?

[Anonymous Coward]

Which is one assumption too much

Re:Time for the BIOS to be EEPROM again?

[Khyber]

Hey, It's a fucking jumper. Like every other goddamned port on the motherboard.

Run a couple of wires off of it, put a fucking physical switch on the outside of the machine. Hold button in while powering machine on. You may now update your BIOS/EFI.

Jesus, was it THAT hard to come up with something so simple for a solution?

Re:Time for the BIOS to be EEPROM again?

[macs4all]

Given that laptops(especially Apple's) are an increasingly heroic enterprise to open;

You need to update your personal Knowledge Base. MacBooks have been very EASY to open since the Unibody case (what is that, like nearly 10 years now???). The only thing difficult to replace on a Mac laptop nowadays is the Keyboard, funnily-enough.

It would be absolute pud for Apple to put a user-accessible pushbutton on the Mobo of a Unibody MacBook. Ten #00 Phillips screws and you're in. If the pushbutton was on the mobo side closest to the bottom-pan, it would be instantly accessible. Kind of like they used to do for the PMC/SMC Reset on older Macs.

Where's my RO-FLASH dip switch?

[Anonymous Coward]

Remind me again why there is not a read-only dip-switch that write-protects the entire firmware? It is not like you cannot hack the damn FLASH since their lockout modes are just as buggy as anything else nowadays, but still...

We were better off using EEPROMs, at least you could write protect those by actually air-gapping the pins required to erase and program the chip.

Not my old macpro 2,1 beasts.. immune :)

[Anonymous Coward]

I tried the rootkit on my macpro 2,1 8 core systems. I have one with a modified boot.efi torun mavericks. as you know the macpro 2,1 has a 32 bit EFI. I modified the bootloader .. it can readthe EFI 32 NVRAM but not write to it. I modified boot.efi to run Linux bare metal on a macpro as well. I didn't want a macos update to modify nvram to a point where I would have to modify my boot.efi code so I wrote boot.efi to access the nvram as read only.

It's a mac and we made it thin so no easy open for

[Joe_Dragon]

It's a mac and we made it thin so no easy open for you also we have storage on a card not a hdd so you really can't take it out easy on all systems. Also say takeing out the HDD in the mac mini can void the warranty or at the very least they can say when you took out the hdd you did ESD damage so people may ship out systems with there HDD that can get hacked at the repair shop.

WHY IS IT WRITEABLE

[Anonymous Coward]

In the first place?

Re:WHY IS IT WRITEABLE

[macs4all]

In the first place?

Do you REALLY have to ask that?

Really?

Doesn't Affect Anyone

[Anonymous Coward]

Macs Vulnerable To Userland Injected EFI Rootkits

Since none of the automakers use Macs (Mac Minis, I would assume) for their Electronic Fuel Injections, this is a non-story.

Re: What sort of fucking idiot are you?

[Anonymous Coward]

You mad bro?

Oh, the true use of EFI...

[Anonymous Coward]

Beware of Greeks bringing gifts.

Re:It's a mac and we made it thin so no easy open

[macs4all]

It's a mac and we made it thin so no easy open for you also we have storage on a card not a hdd so you really can't take it out easy on all systems. Also say takeing out the HDD in the mac mini can void the warranty or at the very least they can say when you took out the hdd you did ESD damage so people may ship out systems with there HDD that can get hacked at the repair shop.

You're so full of shit it must be running out your mouth.

Unibody MacBooks are REALLY easy to open. Remove 10 phillips screws on the bottom-pan and, er, that's it. Replacing the HDD does NOT void the warranty on a Mac mini, unless you are stupid and drop a screw in it and then turn it on or something equally dense. The SSD in the 2015 Retina MacBook Pro is also right in view once you take off the bottom-pan, and is on a plug-in connector. Good luck finding an aftermarket replacement for their PCIe SSD, though.

I'm not sure what you are blathering about "ESD Damage" for, though. If you pet your pussy (cat) while working on the inside of your computer, no matter the brand, you are likely to have an unfavorable outcome.