No amount of EFI rootkit detection will ever remove the possibility that malicious code is running inside the Intel Management Engine (ME), because code inside the ME would run side-by-side with the bootloader and with unlimited permissions.
Unless Intel provides source code for the ME, it is impossible to 100% know whether unauthorized code is running.
What's with the free advertising? They were not the ones to do the original work with coreboot or removing the non important parts of the ME. If anything, Purism has lied, taken credit for other peoples work and given people a false sense of "privacy" and "security". "Almost completely removed the ME" is not good enough and there is way too much room to do malicious things.
What's your point? Is it that exploit developers are not compensated financially for their work? Exploit developers should find a better business model than their current one. This guy was able to take freely available exploit knowledge and monetize it. If the parties responsible for creating the exploit feel they have some sort of IP claim against them, they should sue. If exploit developers wish to release exploit details for free then the best they can wish for is charity.
You missed the point. It is all about giving credit to those who do the work and make discoveries. It is in poor taste to exploit people in the case of taking their work and not giving any credit to those that made their business model possible.
Reproducible builds is a very important part of knowing you are secure, and in the absence of that at least being able to flash on your own compilation.
Well even with reproducible builds how do you check what actually is running there? That'd be the ME reporting "I'm running version X" without a way to really verify it. Also if you flashed it you cannot be 100% sure there is no other component that is still running a rootkit.
It includes a few more details about what was released:
It extracts EFI firmware from flash ROM memory
automatically if the firmware file is not
specified.
We recommend generating an EFI whitelist after
purchasing a system or when you are sure it has
not been infected:
# chipsec_main -m tools.uefi.whitelist -a generate
Then check the EFI firmware on your system
periodically or whenever you are concerned, such
as when a laptop was left unattended:
...
An analysis of the approach they are taking would lead to some pretty easy improvements.
Finally some tools for this. Very good.
Would this be the first reasonably doable method for extracting all the blobs? Seem like it must be a well-needed foundation to build on for security companies.
But...
We recommend generating an EFI whitelist after
purchasing a system or when you are sure it has
not been infected
Not that I have a better suggestion, but with interdicted shipments and other vulnerable points along the supply chain before a system is in the care of its owner, it doesn't exactly seem like a sure bet that it's clean on arrival.
How would one otherwise be "sure it has not been infected"? Any feasible ways?
Next step would be to provide lists of known good signatures from some controlled environment, or at least a consensus system to know whether the version one finds matches the version others have?
I'm assuming not all of the machines from the factory will be infected. Because if that were so, then the chances of being found out is high and consequences would be dire for the manufacturer.
If my assumption is correct then buying a retail machine and comparing its firmware to the one you order with your credit card should be fine.
> How would one otherwise be "sure it has not been infected"? Any feasible ways?
If you are willing to assume they aren't infecting every computer. Walk into a random brick and mortar store and buy it there.
If you're paranoid to the point where you don't trust the people at a random brick and mortar store, point at a display model (or if they have non-display models visible one of those) and insist on that one in particular, without it leaving your sight at any point in time.
Of all the attacks a nation state could do, surely finding a few talented people to get PhDs in the appropriate fields and go to work at Intel and collect a paycheck along with a nice stipend from the nation state is likely among the easiest.
Why bother with employees - just go give money to intel to do this. Intel as a system is designed to produce chips that work a certain way, and my understanding is that said system is rather good at what it does, dedicating the time and energy of many rather smart people to making sure things work the way they're supposed to. Why risk throwing a monkey wrench into such a system when you can just point it in a different direction?
AT&T and Verizon don't have 'plant' employees. Much simpler - and legally, safer - to just give the bag of money straight to the corporation.
There's more than one country interested in pulling off these attacks. The US can say, "Do us this favor and we won't look too hard at your tax avoidance schemes," but China or Russia might have an easier time planting a few employees.
When you have the kind of money and influence that the NSA and CIA have, you probably do both.
As for other friendly and less-friendly nations, I'd be very surprised to learn that there weren't any other nations represented in the ranks of Intel engineers.
I'm not sure it's all that easy, since a) you can't know exactly how good someone is going to turn out to be (you can probably get close through), and b) you can't tell what Intel will be hiring for later, and c) to increase your odds you probably want more than a few people in this program to achieve at least a few people being hired in positions that are useful.
That said, the main hurdles seem to be managing people and funds, which government agencies seem pretty good at figuring out. So maybe not all that easy, but maybe not particularly hard either. The biggest problem might be keeping it secret, given the number of people that might need to be involved that are clandestinely working for a TLA but not as their main job and not steeped in the culture of secrecy.
Isn't it unlikely that an individual engineer (or even a handful) could effect a design level compromise on such a massive project as building a processor? Not only because of the managerial oversight they'd have to circumvent, but because of the overall system complexity. As sibs have pointed it, it would seem much more practical to just compromise Intel at a corporate/managerial level.
> Isn't it unlikely that an individual engineer (or even a handful) could effect a design level compromise on such a massive project as building a processor?
Yes, very unlikely. Something like the Intel Management Engine would be a much easier target.
You can reverse engineer the EFI modules, build a whitelist based on known safe code, and then detect subversion at Intel, so this is not a good strategy for serious adversaries.
In theory, sure.
Is it sufficiently simple that people will do it in practice? (I don't know, I expect you would know)
Wouldn't the malicious alterations introduced in a scenario like that most likely be exploitable defects that could be explained away as mistakes? If they accumulate too much around certain people that's suspicious of course, but it seems like it would often be difficult to downright prove that someone intentionally broke the security of a rather complex system.
The point is that it doesn't matter what the typical person will do. All that matters is that somebody, somewhere reverse engineers the EFI binaries, and that it's easy enough for normal people to run a program to check their current EFI against a whitelist of known good EFI binaries.
This is a banal point, except: if the threat is that Intel (or some other huge vendor) backdoors their EFI binaries, it will get out that they did so. It's not "the perfect crime"; it's practically the opposite of that: one guaranteed to be detected, and that will exact maximal damage on the perpetrators when it gets out.
This can be done manually using flashrom [1] tool to read (and write) the SPI (and not only SPI) flash and UEFITool [2] to unpack the corresponding image. I've even done some patching for better support of Intel platforms here [3]. Now doesn't have much time to rebase/cleanup/improve it, but hopefully someone will start from where I've finished. Both tools clearly need more love, and I hope current revelations will help to do that.
I also used flashrom instead because it's very simple to install and use... My problem is trying to verify this against the original (I'm running linux on an old macbookpro), i've got the raw flash dump and extracted the .scap from Apple... but after much searching cannot find a way to extract the raw EFI volume to compare. Any ideas?
Technically all it means, if the error is as advertised, is that the uefi bootscript failed to match. Now, it could be as simple as that UEFI was customized by a vendor. Or it could be something less innocent.
I just reflashed my bios and then rechecked stuff, same thing... I did more research and s3bootscript seems to be associated with secure boot. Which I have disabled.
The entire computing ecosystem appears to be P0wned by various intelligence services. And, its not unique to the CIA or NSA. The Chinese are assumed to have backdoors into most of what ships from their country.
There's a reason the Russians reportedly moved to typewriters.
Hopefully the Russians still remember how they bugged US typewriters in the US Embassy in Moscow. Then they'll be able to check that their own typewriters aren't bugged in a similar fashion: http://www.cryptomuseum.com/covert/bugs/selectric/
It's pretty bloody sad state that we're in that your comment cannot be dismissed as some tin-foil-hat-lunatic, but very reasonable skepticism nowadays.
Macs lack Secure Boot. This tools seems to be for non-Secure Boot computers. IF it's a Secure Boot system, rootkits aren't supposed to happen, and if they do then there's a hole somewhere that needs fixing.
I'd like to think the existing firmware verifies the signature of a replacement firmware before permitting the replacement. Otherwise we have problems. But at runtime, I'm not aware if there's any such thing as firmware doing a self verification.
EFI binaries though are expected to be signed or they won't execute, that's the point of Secure Boot, and it includes bootloaders and the kernel all being signed. Most Linux distros I'm aware of also sign their modules because permitting unsigned modules could allow you to inject malware right into the kernel just by loading a compromised kernel module.
Unless Intel provides source code for the ME, it is impossible to 100% know whether unauthorized code is running.