Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Security Industry Incapable of Finding Firmware Attackers

Unknown Lamer posted about 6 months ago | from the just-use-coreboot dept.

Security 94

New submitter BIOS4breakfast writes "Research presented at CanSecWest has shown that despite the fact that we know that firmware attackers, in the form of the NSA, definitely exist, there is still a wide gap between the attackers' ability to infect firmware, and the industry's ability to detect their presence. The researchers from MITRE and Intel showed attacks on UEFI SecureBoot, the BIOS itself, and BIOS forensics software. Although they also released detection systems for supporting more research and for trustworthy BIOS capture, the real question is: when is this going to stop being the domain of research and when are security companies going to get serious about protecting against attacks at this level?"

cancel ×

94 comments

Sorry! There are no comments related to the filter you selected.

Least interest (0)

i kan reed (749298) | about 6 months ago | (#46525125)

The thing is, while these are the hardest to fix and address of attacks, they're among the least useful for attackers. You can't spam people from BIOS. You can't really keylog and transmit over TCP from BIOS.

The operating system is as useful to attackers as it is to us other programmers.

Re:Least interest (2, Insightful)

flyingfsck (986395) | about 6 months ago | (#46525157)

Wrong. All an infected BIOS call needs to do is launch a process that will keep running and do its damndest when the system is up.

Re:Least interest (2)

K. S. Kyosuke (729550) | about 6 months ago | (#46526283)

The problem is, firmware is *tiny*. There is only so much it can be capable of. No matter how much ingenuity the attackers will put into its programming, the attack won't be able to survive aggressive threat mitigation actions such as airgapping the computer. Even recording and monitoring all the incoming and outgoing network traffic and using the computer in a sufficiently restricted way would at least tell you if something is going on. It's like with submarines, they're only stealthy until they pump out a torpedo. If you're actually wary of what can happen with your machine or network, it would be a suicidal mission for the firmware to actually do anything detectable.

Re:Least interest (1)

cheater512 (783349) | about 6 months ago | (#46526497)

Have you seen newer motherboards? They have 16mb+ of flash for the BIOS.
Oodles of room to do fun stuff in.

Re:Least interest (3, Funny)

icebike (68054) | about 6 months ago | (#46526529)

Have you seen newer motherboards? They have 16mb+ of flash for the BIOS.
Oodles of room to do fun stuff in.

And they are all infested with UEFI, the worst malware foisted upon the general public in decades.

Re:Least interest (1)

spire3661 (1038968) | about 6 months ago | (#46526653)

Modern motherboards (even cheap ones) can access the filesystem in BIOS.

Re:Least interest (1)

K. S. Kyosuke (729550) | about 6 months ago | (#46527051)

That's not what I had in mind. You can't cram a strong AI system into it. Without that, the machine would have to be fully connected for the exploit to be adaptive to any possible attack mitigation technique. On its own, it can't perform miracles like adapting to software systems that didn't exist when the firmware was written (for example, a new file system, since you're mentioning that - or whole kernels, for that matter). Not without visibly breaking something.

Re:Least interest (1)

The123king (2395060) | about 6 months ago | (#46527611)

And? Malware get depreciated quicker than any other type of software, due to exploited getting found and fixed. Obviously any malware targeted at firmware has an air or permanence to it, but even that will get depreciated when the hardware is replaced or firmware upgraded.

Also worth noting is it depends on the particular device being targeted. For example, the firmware in the SCADA systems Stuxnet targeted is completely reliant on the PC connected to it. Disable the PC and you effectively disable the malware. On the other hand, BIOS/UEFI exploits could be programmed to be OS agnostic, meaning that no matter how often you reformat your disks and no matter what OS you install, the malware could potentially still update itself over ethernet and wreak havoc. Cellphone baseband firmware is also susceptible to this sort of "sophisticated" attack.

In the end, almost all firmware is worth attacking by someone somewhere. As malware becomes more sophisticated, firmware will be targeted more often, and malware such as Stuxnet may well become the norm.

Re:Least interest (0)

Anonymous Coward | about 6 months ago | (#46530891)

So make a firmware malware which only connects to a particular IP and actually download the payload, which can be updated with all the newest malware tricks and support for all sort of stuff.

Don' some bios already have support for TCP/IP, etc build in?

Re:Least interest (0)

Anonymous Coward | about 6 months ago | (#46527873)

In the old days it wouldn't have mattered in the slightest. As soon as the kernel transitioned to 32 bit that code was dead code as the the transition happens with all interrupts masked and the next event is rewrite the IVT.

Re:Least interest (1)

Anonymous Coward | about 6 months ago | (#46525165)

Yes you can.

Especially if the system is attached to a network with a DHCP server.

UEFI is equivalent to an OS, and is written the same way.

BIOS is a little bit more limited - but not much. You can include a DHCP client to get a local IP number.

Re:Least interest (1)

Jeremiah Cornelius (137) | about 6 months ago | (#46525505)

Big problem with BIOS is that it is board/chipset-specific. And very tiny. Not un-doable, but not scalable.

These were some of the BIOS constraints that EFI/UEFI were created to surpass.

Re: Least interest (0)

Anonymous Coward | about 6 months ago | (#46531477)

And how many BIOS vendors are there supplying BIOS products to board vendors? Less than a handful. BIOS on our systems is not that board specific after all.

Re:Least interest (3, Interesting)

EdZ (755139) | about 6 months ago | (#46525177)

What you CAN do is exploit an otherwise secure OS so that you CAN do those things in spite of OS-level security methods.

I miss the days of needing a move a jumper in order to flash the system ROM. I've seen plenty of gaudy 'overlocking' boards with push-buttons on the motherboard itself for various esoteric functions. A toggle-switch for BIOS-write-enable would be a relatively cheap addition, and manufacturers can market the board with some extra security buzzwords.

Re:Least interest (4, Insightful)

rtb61 (674572) | about 6 months ago | (#46525627)

Which means basically when they start intercepting hardware between the manufacturer and the user, security becomes an impossible mind fuck. Once it all shifted to firmware and hardware hacks the security game is over. Parallel networks where the inside network is fully air gapped from outside networks and the building itself is secured from wireless communications. Basically all internet function are done on disposable net books, this more for typical businesses rather than internet business. Apparently Russian security has gone back to typewriters and hard copy for the most secure documents, actual physical penetration is required. With the NSA continuing to fuck around with security, how long will it be before banks go back to manual systems and internet banking becomes a memory.

Re:Least interest (1)

K. S. Kyosuke (729550) | about 6 months ago | (#46526307)

and internet banking becomes a memory.

That depends. No level of compromising your (general purpose) computer should be able to defeat the security of your manually operated hardware token/calculator.

Re:Least interest (0)

Anonymous Coward | about 6 months ago | (#46526623)

rtb61 said intercepting hardware between the manufacturer and the user, not intercepting computers only. It's safe to assume the NSA can send gag orders to Yubikey too.

Re:Least interest (1)

psydeshow (154300) | about 6 months ago | (#46545847)

and internet banking becomes a memory.

That depends. No level of compromising your (general purpose) computer should be able to defeat the security of your manually operated hardware token/calculator.

Attacker has control of my computer. I read a number off my MFA device and input it into the bank's form along with my username and password.

Now attacker has a banking session they can do whatever they want with. How has having a hardware token prevented them from attacking me?

Re:Least interest (1)

K. S. Kyosuke (729550) | about 6 months ago | (#46546595)

No, they can't. At most they would be able to, say, view your account balance etc., but the token can be (and most of the time is) used to authenticate any transaction based on its input values (how much to transfer, where, with what payment codes etc.).

Re:Least interest (4, Informative)

Anonymous Coward | about 6 months ago | (#46525191)

Nice try, but it runs in ring 0, so it can jump into the kernel anywhere it wants.

Re:Least interest (0)

Anonymous Coward | about 6 months ago | (#46525427)

+1 Internets for knowing what you are talking about. Good form old man, good form.
 

Re:Least interest (1)

some old guy (674482) | about 6 months ago | (#46525495)

Seconded. Hear, hear!

Re:Least interest (1)

andyhhp (1373567) | about 6 months ago | (#46528741)

Nice try, but it runs in ring 0, so it can jump into the kernel anywhere it wants.

Worse than that after boot, the BIOS runs in System Management Mode, which is delberatly designed to be non-interceptable by the OS.

Re:Least interest (0)

Anonymous Coward | about 6 months ago | (#46525205)

You can do anything you want from BIOS. Haven't you heard about SMM?

Re:Least interest (1)

Phreakiture (547094) | about 6 months ago | (#46525755)

The NSA implant known as SOUFLETROUGH allegedly uses SMM and is even referenced on the SMM page on Wikipedia [wikipedia.org] .

Re:Least interest (0)

Anonymous Coward | about 6 months ago | (#46525209)

but you can operate outside kernal and you can happily run programs that look into the kernal and the OS has no clue they are there becouse it can not see outside its own kernal

Re:Least interest (1)

K. S. Kyosuke (729550) | about 6 months ago | (#46526311)

Well, that's what you get for still using a C-64. ;-)

Re:Least interest (0)

Anonymous Coward | about 6 months ago | (#46525215)

The BIOS has bare back access to the hardware. Why cant it log the keyboard and dump it out the Ethernet? Why cant it access the ram directly?

Re:Least interest (1)

icebike (68054) | about 6 months ago | (#46526595)

The BIOS has bare back access to the hardware. Why cant it log the keyboard and dump it out the Ethernet? Why cant it access the ram directly?

The term you were looking for is "bare metal".
Bare back is something totally different.

Re:Least interest (1)

climb_no_fear (572210) | about 6 months ago | (#46528047)

Sorry, but "bare back access" was so titillating that it distracted me from finishing the rest of your post...

Then there are remte admin tools such as Intel AMT (1)

Ungrounded Lightning (62228) | about 6 months ago | (#46531027)

The BIOS has bare back access to the hardware. Why cant it log the keyboard and dump it out the Ethernet? Why cant it access the ram directly?

Built-in threats include more than just BIOS. At least one, and probably most, chip makers build in backdoors that do exactly what you describe, and much more. It's built right into the silicon, too.

Modern laptops and desktops come with remote administration tools built into the chips on the board. (The vendors tout this as a feature, simplifying administration of a large company's workstations. It's easier and cheaper to build it into everything than to be selective, so it's in the machines sold to individuals, too.)

One example: Intel Active Management Technology (AMT) [wikipedia.org] and its standard Intelligent Platform Management Interface (IPMI) [wikipedia.org] , the latter standardized in 1998 and supported by "over 200 hardware vendors". This is built into the northbridge (or, in early models, the Ethernet) chip).

Just TRY to get a "modern laptop" (or desktop), using an Intel chipset, without this feature.

You can't disable it: Dumping the credentials or reverting to factory settings just makes it think it hasn't been configured yet and accept the first connection (ethernet or WiFi, whether powered up or down) claiming to be the new owner's sysadmins.

If the NSA doesn't know how to use this to spy on, or take over, a target computer, they aren't doing their jobs.

Some of the things this can do (from the Wikipedia articles - see them for the footnotes):

Hardware-based AMT features include:

amt.feature:Encrypted, remote communication channel for network traffic between the IT console and Intel AMT.

amt.feature: Ability for a wired PC (physically connected to the network) outside the company's firewall on an open LAN to establish a secure communication tunnel (via AMT) back to the IT console. Examples of an open LAN include a wired laptop at home or at an SMB site that does not have a proxy server.

amt.feature: Protected Audio/Video Pathway for playback protection of DRM-protected media.

Additional AMT features in laptop PCs

Laptops with AMT also include wireless technologies:

michael@shuttle:~/nomad-michael/letters$ cat amt.feature
Modern laptops and desktops come with remote administration tools built into the chips on the board. (The vendors tout this as a feature, simplifying administration of a large company's workstations. It's easier and cheaper to build it into everything than to be selective, so it's in the machines sold to individuals, too.)

One example: Intel Active Management Technology (AMT) [wikipedia.org] and its standard Intelligent Platform Management Interface (IPMI) [wikipedia.org] , the latter standardized in 1998 and supported by "over 200 hardware vendors". This is built into the northbridge (or, in early models, the Ethernet) chip).

Just TRY to get a "modern laptop" (or desktop), using an Intel chipset, without this feature.

You can't disable it: Dumping the credentials or reverting to factory settings just makes it think it hasn't been configured yet and accept the first connection (ethernet or WiFi, whether powered up or down) claiming to be the new owner's sysadmins.

If the NSA doesn't know how to use this to spy on, or take over, a target computer, they aren't doing their jobs.

Some of the things this can do (from the Wikipedia articles - see them for the footnotes):

Hardware-based AMT features include:

Encrypted, remote communication channel for network traffic between the IT console and Intel AMT.

                Ability for a wired PC (physically connected to the network) outside the company's firewall on an open LAN to establish a secure communication tunnel (via AMT) back to the IT console. Examples of an open LAN include a wired laptop at home or at an SMB site that does not have a proxy server.

                Remote power up / power down / power cycle through encrypted WOL.

                Remote boot, via integrated device electronics redirect (IDE-R).

                Console redirection, via serial over LAN (SOL).

                Keyboard, video, mouse (KVM) over network.

                Hardware-based filters for monitoring packet headers in inbound and outbound network traffic for known threats (based on programmable timers), and for monitoring known / unknown threats based on time-based heuristics. Laptops and desktop PCs have filters to monitor packet headers. Desktop PCs have packet-header filters and time-based filters.

                Isolation circuitry (previously and unofficially called "circuit breaker" by Intel) to port-block, rate-limit, or fully isolate a PC that might be compromised or infected.

                Agent presence checking, via hardware-based, policy-based programmable timers. A "miss" generates an event; you can specify that the event generate an alert.

                OOB alerting.

                Persistent event log, stored in protected memory (not on the hard drive).

                Access (preboot) the PC's universal unique identifier (UUID).

                Access (preboot) hardware asset information, such as a component's manufacturer and model, which is updated every time the system goes through power-on self-test (POST).

                Access (preboot) to third-party data store (TPDS), a protected memory area that software vendors can use, in which to version information, .DAT files, and other information.

                Remote configuration options, including certificate-based zero-touch remote configuration, USB key configuration (light-touch), and manual configuration.

                Protected Audio/Video Pathway for playback protection of DRM-protected media.

Additional AMT features in laptop PCs

Laptops with AMT also include wireless technologies:

                Support for IEEE 802.11 a/g/n wireless protocols
 

                Cisco-compatible extensions for Voice over WLAN

This just happens to be one I'm familiar with. I don't know whether (or which) other chip makers (such as AMD) have similar "features" built in as well (though I'd be surprised if they didn't, since they want to sell into big companies, too).

But you can and it's useful (4, Insightful)

dutchwhizzman (817898) | about 6 months ago | (#46525225)


Most bioses now have a complete TCP/IP stack for things like ipmi. Keylogging only requires a few simple routines to do as well; plenty of room to implement that in current flash chips on main boards.

Hiding in firmware makes you resilient and virtually undetectable on the "normal storage". A rudimentary base to pull next stage software in that will "bootstrap" the full malware once the OS installed is all that is needed. The full malware can be fragmented and re-use existing binaries so it won't be detected. You need a trusted platform and guaranteed "safe" steps to be able to reasonably trust your computer and when firmware contains holes or malicious code, there are plenty of people that don't work for the NSA that can actually build a competent attack for that.

Re:But you can and it's useful (1)

Kremmy (793693) | about 6 months ago | (#46525357)

Most BIOSes + NICs have that little PXE booting stack hanging out in the option ROM. It's really not that farfetched by any means.

Re:Least interest (1)

mlts (1038732) | about 6 months ago | (#46525227)

On some machines, they have out of band management features, even dedicated NICs for this purpose. Get full access to a BIOS, and the machine can easily have a functioning IP stack and be at the control of an attacker even if the machine has no OS present.

Another item would be a flashable BIOS like a security issue with some Apple keyboards. Nothing beats using the keyboard controller itself for a keylogger.

Re:Least interest (2)

BIOS4breakfast (3007409) | about 6 months ago | (#46525247)

Actually most BIOS (legacy or UEFI) have a network stack of some sort in order to support PXE boot. Recall that the PoC BIOS malware Rakshasa (https://media.blackhat.com/bh-us-12/Briefings/Brossard/BH_US_12_Brossard_Backdoor_Hacking_Slides.pdf) used the open source SeaBIOS and iPXE network stacks to perform networking from the BIOS. And here's a talk where some McAfee and Intel folks talked about how keylogging can be done from UEFI thanks to function pointer hooking (http://intelstudios.edgesuite.net/idf/2012/sf/aep/EFIS003/EFIS003.html I couldn't find the slides, just video) And you seem to have missed the point about spammers != state-sponsored attackers who clearly find attacking at this level plenty practical.

Re:Least interest (1)

Kremmy (793693) | about 6 months ago | (#46525263)

The vast, vast majority of personal computer units with integrated LAN cards happen to have network boot capability built in. It's been there since before they were an integrated component, even. Intel and Realtek make most of the ethernet chipsets I see around, and they both use a pretty bog standard PXE network booting stack. BIOS hackers would be acutely aware of it, I wouldn't be surprised if that's been exploited in some strikingly silly manner and used for this kind of thing.

Very wrong (0)

Anonymous Coward | about 6 months ago | (#46525633)

The most useful thing about the BIOS level hacks is it's ability to persistently keep a system infected with whatever higher level stuff you want to use. I can imagine how it must feel to resign yourself to having to reformat/re-install your OS, only to not solve the problem.

Re: Very wrong (1)

imperfect cloner (3584487) | about 6 months ago | (#46531503)

That's exactly what Mebromi malware does. Its BIOS rootkit component restores infected Master Boot Record (MBR): http://www.webroot.com/blog/20... [webroot.com]

So we should call it 'infirmware' ? (0)

scorp1us (235526) | about 6 months ago | (#46525155)

Because you know, if it isn't secure, then it's not firm.

Re:So we should call it 'infirmware' ? (1)

climb_no_fear (572210) | about 6 months ago | (#46528079)

.... then it's not firm.

No, it's too easy ...

write protect (1)

wkk2 (808881) | about 6 months ago | (#46525167)

A good start would be a list of hardware vendors that sell equipment that have hardware jumpers or switches that write protect the BIOS and other flash devices.

Re:write protect (0)

Anonymous Coward | about 6 months ago | (#46525261)

Doesn't help if the BIOS was compromised at the factory with either a NSL or just a bribe.

I suggest something like putting the bios on a micro-sd card that you can pull out and use other tools to examine easily.

Re:write protect (1)

BIOS4breakfast (3007409) | about 6 months ago | (#46525273)

While hobbiests who use custom motherboards are familiar with write protect jumpers, they are going the way of the dodo. They've been all but phased out on OEM laptops, and are going that way on desktops too.

The important write protects are whether the BIOS configures itself as locked or not after it's booted far enough to determine there are no BIOS updates pending. You can check if your BIOS is open or closed to attackers by running Copernicus [mitre.org] or Chipsec [github.com] .

Duh, what should we do? (2)

DriveDog (822962) | about 6 months ago | (#46525171)

So... open source everything, that anyone can compile to executable. Then focus on obfuscated code, about the only avenue left for malicious code. It only takes one major manufacturer to publicly announce that "we're publishing our code so that it can be verified, unlike our competitors" for it to spread to the competitors.

Re:Duh, what should we do? (0)

Anonymous Coward | about 6 months ago | (#46525289)

You know who reviews open source code seriously?

Fucking nobody.

Reviewing open source code (0)

Anonymous Coward | about 6 months ago | (#46525397)

Other committers on the project are likely review eachother's commits, especially in OpenBSD and FreeBSD

Re:Duh, what should we do? (3, Interesting)

jc42 (318812) | about 6 months ago | (#46525493)

You know who reviews open source code seriously? Fucking nobody.

Oh, I dunno 'bout dat. I recall a few years ago, getting an informative email from one of djb's folks, telling me how to exploit an open-source program that I was using in the software behind a web site that I was responsible for. I ran their test, dug into the code and fixed the problem (and several similar problems in other parts of the code), and sent them a nice letter thanking them for their help. I also forwarded their email and my patches to the author of the program, but I didn't hear back from him.

This only fails to qualify as "seriously" if you dismiss all of academia as not serious. In reality, that's where you'll find most of the people who take security seriously. You don't much find them in "industry" (as the summary puts it), for management reasons that are well-understood by pretty much anyone who has ever tried to get security problems fixed in a corporate-management environment.

Re: Duh, what should we do? (0)

Anonymous Coward | about 6 months ago | (#46525523)

Ever wondered where companies like Coverty finds tons of source code to test their software?

Re:Duh, what should we do? (1)

Jeremiah Cornelius (137) | about 6 months ago | (#46525527)

You know who reviews open source code seriously?

Fucking nobody.

What!? You call the NSA "fucking nobody"? Maybe nobody will fuck them, but that's different...

Re:Duh, what should we do? (0)

Anonymous Coward | about 6 months ago | (#46526765)

You know who reviews open source code seriously?

Fucking nobody.

Hyperbole like this can be misleading when all it takes is one (1) person to notice a problem.

Re:Duh, what should we do? (1)

BIOS4breakfast (3007409) | about 6 months ago | (#46525321)

It only takes one major manufacturer to publicly announce that "we're publishing our code so that it can be verified, unlike our competitors" for it to spread to the competitors.

OEM1 releases full source
OEM2 fires all BIOS developers and leeches off OEM1
OEM1 has the privilege of maintaining a BIOS development workforce for the benefit of their competitors

Though maybe that would work as a feint to eventually put competitors at a disadvantage ;-)

Also, believe it or not, OEMs and places like AMI, Phoenix, etc do actually try to add features down at the firmware level that their competitors don't have, to differentiate themselves and hopefully get a few more sales. E.g. recall the splashtop OSes that were being pimped as the instant-boot solution to get your browsing quickly a while back. Or I feel like I've seen the ability to check your Outlook from BIOS on HPs :-/

Re:Duh, what should we do? (1)

Grishnakh (216268) | about 6 months ago | (#46525483)

Yep, that's why everyone just uses Windows now, since it's freely available thanks to Microsoft releasing the full source code in their Shared Source program. When that happened, other companies just took it and sold it as their own.

Oh wait, that never happened.

Re:Duh, what should we do? (1)

gtall (79522) | about 6 months ago | (#46525753)

Nah, competitors will steal your code and put you out of business. And publishing your code is more or less meaningless unless there's a legion of qualified people willing to examine it. And why would they do that? What's in it for them? Aside from a few big FOSS projects (Linux, et. al.), the only people looking at your code are either miscreants, your competitors, or your country's competitors.

Joe Sixpack: I wanna buy a router for my XP machines.
Eve Clerk: Well, here's a Cisco router, it works well. And here's a FOSS router, it works well, AND its code is published so that it's supposed to be more secure.
Joe: How much do they cost?
Eve: The Cisco is $99.98. The FOSS is $99.99.
Joe: I'll take the Cisco, a penny saved is a penny earned.

Use a jumper (3, Funny)

techno-vampire (666512) | about 6 months ago | (#46525187)

I can remember when there was a jumper on the motherboard that had to be shifted before it was possible to flash the firmware. If all motherboards had that, the only way an attacker could get malware into the BIOS (or whatever other firmware they wanted to target) would be by tricking the user into changing the jumper. Not only that, many of the users who'd be foolish enough to fall for that kind of trick wouldn't have the confidence to open up their box and play with the hardware. Not all, of course, but then, no security measure is 100% effective.

Re:Use a jumper (2)

scorp1us (235526) | about 6 months ago | (#46525223)

While I am not an expert, I don't believe that we're just talking about reflashing here. It is possible that the firmware relied on to perform operating system functions in exploited all the way back in user-space. Some program gets some arguments from somewhere that get passed on to the kernel level, the kernel then passes that to the hardware and voila, exploited.

Re:Use a jumper (1)

techno-vampire (666512) | about 6 months ago | (#46525339)

No, what you're thinking of is drivers. Firmware [wikipedia.org] is held in non-volatile memory and executed there so that it's ready to be used the moment the device is turned on, and so that it can't easily be modified.

Re:Use a jumper (1)

scorp1us (235526) | about 6 months ago | (#46525395)

And what do the drivers communicate with? The firmware.

Your normal device will provide a memory mapped structure to the device where values are read and stored. They use IOCTLs to command the hardware usually through interrupts. The Firmware has the corresponding data structure on its side. I'm not an expert but I have written a kernel driver or two, but not recently.

Re:Use a jumper (2)

techno-vampire (666512) | about 6 months ago | (#46525507)

And what do the drivers communicate with? The firmware.

Well yes, of course. However, drivers tend to be OS specific, and can be reloaded fairly easily if infected. TFA is talking about getting malware into the firmware, which has to be OS agnostic and is somewhat harder to disinfect.

Re:Use a jumper (1)

Sam Cornwell (3583861) | about 6 months ago | (#46525487)

Yeah that's basically right. UEFI specifies the need for the storage of non-volatile variables for some configuration or metadata (which can be modified from admin userland as you said). All of the BIOSes I've seen have used the flash chip itself to store this data, therefore the chip must be modifiable and a jumper would not work with these designs. There are mechanisms that can be used to allow writability of certain regions of the chip, but often they are not used. Even when they are used, there are still bugs.

Re:Use a jumper (1)

mlts (1038732) | about 6 months ago | (#46525359)

I remember that as well. Yes, it is easier to just double-click a program and have it flash a BIOS... but it is nice to have security not just relying on 1-2 crypto signatures which might be compromised.

If not a hardware jumper, perhaps a dedicated mode in firmware where the machine needs rebooted to. Then a UEFI application can be run for the actual BIOS upgrade where it would display the would-be firmware's cryptographic hash (preferably both SHA-3 and MD5), check and display signatures, then either have two sections for BIOS, or perform the flash as a transaction (either it completes 100%, or it backs out completely), then calls it done.

Of course, a lot of enterprises have a need for being able to flash machines without someone physically present at the console, so there will need to be a mechanism to handle this securely (in a way separated from the BIOS signatures.)

Re:Use a jumper (0)

Anonymous Coward | about 6 months ago | (#46527451)

It doesn't even have to be a jumper. Hell, it could be a 'flip this if you want to flash the BIOS' hard switch - that prevents anything but media plugged into a dedicated port on the motherboard from communicating with the BIOS chip while it's being updated.

These attacks are too easy to prevent. Cheap hardware countermeasures. It's not fucking rocket science and it's actually how things used to be, as you said.

How can you? (0)

Anonymous Coward | about 6 months ago | (#46525235)

If the firmware is compromised all you're going to see at the executable level is "everything is A-OK, we're all fine here."

They're not. (2)

IWannaBeAnAC (653701) | about 6 months ago | (#46525255)

They're never going to fix this. It isn't just a matter of publishing source code, it affects the hardware too. It needs hardware protection on the flash, for example, so that you can control, at a hardware level (eg by a button on the device) whether the flash is writable.

But by now, all of the manufacturers are so infiltrated by other agencies, the NSA, foreign governments, and business interests (having the user in control of their own security directly contradicts the aims of DRM, not to mention marketing companies); this all conspires against ever having any security over your own firmware.

Build it yourself is probably the best bet. And the nice thing is that this is becoming more practical. The biggest problem is that there is no way to verify the hardware at the chip level, but with careful design it is possible to get reasonably good security without 100% trust in all of the individual components.

But for the overwhelming majority of people, who are not motivated or able to build their own, their tech is doomed to be compromised. I don't think there is anything that can be done about that. It is a political issue, rather than technical. And in all "democracies" that I can think of, the political will is against it.

Re:They're not. (0)

Anonymous Coward | about 6 months ago | (#46525533)

"Fixing" it is the wrong term to be used here in my opinion. Disabling flash writes isn't a viable solution, since that would stop important BIOS updates as well that protect against the same problems (and you don't want your system to persist its old BIOS, that's not a good way to go).

Making BIOS open source and validating the binaries when they're executed is a good start. Preferably by other hardware (decent) or by outside components on the internet (better) that act as a root of trust.

Re:They're not. (1)

Arker (91948) | about 6 months ago | (#46527127)

"Disabling flash writes isn't a viable solution, since that would stop important BIOS updates as well that protect against the same problems (and you don't want your system to persist its old BIOS, that's not a good way to go)."

Having a physical read-write switch does not prevent BIOS updates, you simply turn it off when you are going to do a legitimate upgrade, and then turn it back on afterwards. It just prevents BIOS updates from being installed stealthily from a distance.

Re:They're not. (1)

Cryptodd (3583923) | about 6 months ago | (#46527897)

There are foundation technologies to address this - Intel Trusted Execution Technology (TXT) and Trusted Platform Modules (TPMs). You can take measurements with TXT and store them securely in TPMs. Attesting remotely will tell you whether or not you have a good/valid/trusted system that has good/valid/trusted measurements from the TPM. This is not a lost cause, and there are companies out there taking advantage of TXT & TPMs to establish trust. This can shrink the perimeter down to the CPU. If your CPU is backdoored, all bets are off. But you have to establish a root of trust somewhere.

Attacks on UEFI... (3, Informative)

Obfuscant (592200) | about 6 months ago | (#46525275)

Would that include "attacks" that allow OSs other than the officially state-approved and certificate-signed ones to be booted. Like that hacker-prone and highly illegal "Linux" thing I've been hearing about? I'm glad that researchers are protecting us against such flim-flammery and obviously dangerous stuff.

SecureBOOT not secure (0)

Anonymous Coward | about 6 months ago | (#46525379)

In a way I find it hilarious that BIOS and UEFI both are vulnerable and that taking away the hardware owner's choice through SecureBOOT doesn't fix it.

And that when back in the day I had a systemboard with a jumper set to make the flash not writable. This is why you want some things to be simple and reliable and with little need to touch them. The resulting low frequency need to use enables things like requiring physical access and changing a jumper for the duration.

In that sense, the peecee platform is hopelessly inadequate and the bolt-on LOMs, ILOs, and such more, even UEFI, are hopelessly complicated where they shouldn't be and under-featured where they should be more powerful. Like, oh, supporting doing a full OS install over nothing but a single serial line, including configuring the network and fetching installation stuff over said network, and configuring the base install, still over serial line. That level of simplicity is entirely absent in the wintendo ecosystem, and is the source of many defects and problems, large and small.

I'm not saying that if every peecee shipped with openboot we wouldn't have infections like this. But at least tracking it down would've been a little less complicated.

Re: SecureBOOT not secure (2)

Sam Cornwell (3583861) | about 6 months ago | (#46526089)

You're conflating a lot of things.

-Secure boot is a UEFI protocol not a Windows 8 feature
-UEFI secure boot is part of Windows 8 secured boot architecture
-Secure boot doesn’t “lock out” operating system loaders, but is a policy that allows firmware to validate authenticity of components
-OEMs have the ability to customize their firmware to meet the needs of their customers by customizing the level of certificate and policy management on their platform
-Microsoft does not mandate or control the settings on PC firmware that control or enable secured boot from any operating system other than Windows

Above is from http://blogs.msdn.com/b/b8/arc... [msdn.com] with some modifications.

In the Intel reference UEFI implementation I have used, I could easily add and remove keys and customize it to implement the trust policy I wanted. This is up to your OEM to implement these features, nothing to do with Microsoft. For their certification program, Microsoft *requires* that SecureBoot is disableable and that the secureboot policy (list of trusted signatures) is customizable by a physically-present user. People whining that they can't install Linux on their systems because of Microsoft have no idea what they are talking about.

Visibility (2)

maz2331 (1104901) | about 6 months ago | (#46525393)

There is really no way for any code running on top of another layer to verify that lower layer's integrity - it has to rely on what is reported and a malicious BIOS or UEFI layer can simply just lie to it. Hell, it's possible for a low-level hypervisor to run another, clean, BIOS/UEFI and simply virtualize every piece of hardware in the box. Likewise, it can block visibility of any traffic going in and out that it desires. This type of security has to happen at the network level instead - something outside of the device has to detect the suspicious traffic that such an attack must generate in order to be useful. That in turn requires that the networking gear has to be trustworthy and not itself owned by the attacker or have any backdoors installed at the factory (or chip maker, or etc etc).

Re:Visibility (1)

blueg3 (192743) | about 6 months ago | (#46525573)

There is really no way for any code running on top of another layer to verify that lower layer's integrity - it has to rely on what is reported and a malicious BIOS or UEFI layer can simply just lie to it.

Theoretically, yes. Practically, it's often not that easy to "just lie to it". (So, in practice, it becomes an arms race of effort just like everything else.)

For example:

Hell, it's possible for a low-level hypervisor to run another, clean, BIOS/UEFI and simply virtualize every piece of hardware in the box.

That's easy to detect through timing attacks, it turns out. You would also have to be very careful to exactly replicate the behavior of the hardware you're virtualizing, or that's detectable, too.

something outside of the device has to detect the suspicious traffic that such an attack must generate in order to be useful

Now, talk about difficult problems! The easy part would be having trustworthy networking gear. The hard part would be that "detect the suspicious traffic" boils down to "detect a side-channel attack used for exfiltrating data", which is somewhere in between very difficult and impossible.

Re:Visibility (1)

Cryptodd (3583923) | about 6 months ago | (#46527931)

You can validate the system is in a known, good state at boot-time, but that does not apply at run-time. You can use Intel Trusted Execution Technology (TXT) to measure the system is in a known, good state and store those measurements in the Trusted Platform Module (TPM). When you attest remotely, if the whitelist values do not match, you do not admit the system into your infrastructure. This approach can take measurements up to the VM-layer (hardware/firmware/BIOS/hypervisor). There are solutions to attest at boot-time (PrivateCore vCage), but run-time is another matter.

Re:Visibility (0)

Anonymous Coward | about 6 months ago | (#46527937)

There is a solution. It's called accounting for all memory at boot time.

1. Know how much memory you have. Use the keyboard.
2. Enumerate all memory on the system, see if it doesn't match.
3. Turn off all devices and blank-down all I/O memory regions.
You'll either 1) Know by step 2, 2) Crash writing to memory that is owned by the emulator, or 3) Notify the user that they have a trojen when it pages as the HD has to spin up again, or 4) Crash the emulator and have a clean system.

OS is too hard also (1)

CloneRanger (122623) | about 6 months ago | (#46525475)

This is on the heels of an announcement by NIAP that common criteria evaluation of operating systems is too hard:
https://www.niap-ccevs.org/Documents_and_Guidance/ccevs/GPOS%20Position%20Statement.pdf

incentives (2)

Chrisq (894406) | about 6 months ago | (#46525509)

t we know that firmware attackers, in the form of the NSA, definitely exist, there is still a wide gap between the attackers' ability to infect firmware, and the industry's ability to detect their presence.

I bet the NSA can give a lot of incentives to companies not to look for or remove firmware back-doors - or even to introduce them. This could be carrots (lucrative contracts or info on what overseas competition is doing) or sticks (not getting the government contract or the CIO's wife finding out what he said in those phone-calls to his secretary).

Re:incentives (1)

gman003 (1693318) | about 6 months ago | (#46527245)

It doesn't even have to do anything sinister - just say "if you want , we need to be able to audit your source code". They find the security holes themselves, tell the vendor about one or two minor ones to hide their intentions, then use the flaws they didn't disclose to hack others. The vendor wouldn't see anything that makes the NSA look even remotely sinister. Best part is that the vendors who aim for US government contracts, particularly ones needing security audits, will be the ones aiming for other governments' security-sensitive contracts, so you're catching the big fish.

When are security companies going to get serious? (1)

oDDmON oUT (231200) | about 6 months ago | (#46525551)

When the kickbacks dry up.

When? Well, never. (1)

computational super (740265) | about 6 months ago | (#46525603)

When are they going to start taking security seriously? When consumers are willing to pay more money for more secure devices. So, never.

Re:When? Well, never. (0)

Anonymous Coward | about 6 months ago | (#46525807)

When consumers are willing to pay more money for more secure devices

I've got another one of such a jadoodle for you:

"When companies are willing to make a bit less profit so they protect their customers (from easily being hacked)". So, also never.

By the way: A simple motherboard jumper should cost way less than a dime. Guess why it isn't a part of all current motherboards anymore. You guessed it: removing them gave a direct profit.

Re:When? Well, never. (1)

Lumpy (12016) | about 6 months ago | (#46526265)

Why do I have to pay more? I suggest they make less obscene profits and lower executive wages to cover the cost of doing business.

Using Intel TXT and TPMs (0)

Anonymous Coward | about 6 months ago | (#46525649)

You can use Intel Trusted Execution Technologies (TXT) and Trusted Platform Modules (TPMs) in servers to measure that the firmware is in a known, good state for x86 servers. Attesting/validating against a list of known, good values at boot-time would enable you to determine that the server is in a known, good state. There are solutions leveraging TXT and TPMs to protect against this attack vector in Linux servers (example: PrivateCore vCage). A challenge is that some servers do not have TPMs.

Re:Using Intel TXT and TPMs (1)

amorsen (7485) | about 6 months ago | (#46526625)

Can you point me to a signed firmware image which is in a known, good state? One that has been properly independently audited by someone who can be reasonably assumed to not be under the influence of the NSA?

When? (1)

ArhcAngel (247594) | about 6 months ago | (#46525657)

when is this going to stop being the domain of research and when are security companies going to get serious about protecting against attacks at this level?"

As soon as someone with a powerful attorney and deep pockets gets hacked via this vector and sues the OEM into oblivion would be my guess.

There is no Binary choice (1)

WillAffleckUW (858324) | about 6 months ago | (#46525695)

You said they either find the firmware hackers or they don't.

You missed the "it's a feature, not a bug" solution.

Please go back to Logic School.

obvious answer is obvious (1)

Charliemopps (1157495) | about 6 months ago | (#46525955)

When is this going to stop being the domain of research and when are security companies going to get serious about protecting against attacks at this level?

When the NSA stops paying them to ignore it.

The industry is full of shit. (1)

Lumpy (12016) | about 6 months ago | (#46526243)

they CAN deal with this. require a physical jumper on the device to be moved for firmware loading. all devices leave the factory blank and they flash their firmware in house when they arrive.

They dont want to do that, they want the 100,000 items to ship from china and never be touched again. Boo Hoo. man up and touch every item state side to protect your products integrity.

The CEO's bonus check would cover the required costs.

And when are the NSA people responsible for these (0)

Anonymous Coward | about 6 months ago | (#46526299)

This is unacceptable. Someone with a contaminated computer should press charges, subpoena Alexander and the rest of those scumbags and charge them with crimes.

Comment on this story... (1)

sgt_doom (655561) | about 6 months ago | (#46526545)

Just a thought: Intel and MITRE are both Rockefeller companies (the majority share holders in both Apple and Intel were originally the Rockefeller family, by way of Laurence Rockefeller, and I've yet to see anything suggesting that has changed). And, the owners of the semiconductor company (Freescale Semiconductor) well-represented on that missing Malaysian MH 370 flight are the Blackstone Group and Carlyle Group (Blackstone Group began with seed money from David Rockefeller, and its co-founder, Peter G. Peterson, has long been his protege). Interesting confluence of ownership and financing?

Hardware gap (2)

C18H27NO3 (1282172) | about 6 months ago | (#46526573)

At least one of the systems I've owned in the past required a jumper to be set before BIOS could be written to/flashed/modified.
I thought that was a boon and would certainly defeat any nefarious flashing. Something like that should be standard.

Chromebooks (1)

lprofile001 (1293008) | about 6 months ago | (#46527423)

Google tries to get security right for Chromebooks. A read-only portion of the firmware authenticates the read-write firmware. The read-write firmware must be signed by google. You must disassemble the machine to flash the read-only firmware.

I can tell you where they are (0)

Trogre (513942) | about 6 months ago | (#46529671)

I have seen some particularly nasty malware hidden in many BIOSes recently. The payload has the effect of preventing you from installing legitimate operating systems on your own computer without paying large amounts of money to an extortion operation.

So far I have traced the perpetrators as far as Redmond, WA.

I know where they are (1)

Trogre (513942) | about 6 months ago | (#46529747)

I have seen some particularly nasty malware hidden in many BIOSes recently. The payload has the effect of preventing you from installing legitimate operating systems on your own computer without first paying large amounts of money to a large extortion group.

Through my research I have managed to trace the perpetrators to Redmond, WA.

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>