Intel Confirms Alder Lake BIOS Source Code Leaked (tomshardware.com) 61
Tom's Hardware reports:
We recently broke the news that Intel's Alder Lake BIOS source code had been leaked to 4chan and Github, with the 6GB file containing tools and code for building and optimizing BIOS/UEFI images. We reported the leak within hours of the initial occurrence, so we didn't yet have confirmation from Intel that the leak was genuine. Intel has now issued a statement to Tom's Hardware confirming the incident:
"Our proprietary UEFI code appears to have been leaked by a third party. We do not believe this exposes any new security vulnerabilities as we do not rely on obfuscation of information as a security measure. This code is covered under our bug bounty program within the Project Circuit Breaker campaign, and we encourage any researchers who may identify potential vulnerabilities to bring them our attention through this program...."
The BIOS/UEFI of a computer initializes the hardware before the operating system has loaded, so among its many responsibilities, is establishing connections to certain security mechanisms, like the TPM (Trusted Platform Module). Now that the BIOS/UEFI code is in the wild and Intel has confirmed it as legitimate, both nefarious actors and security researchers alike will undoubtedly probe it to search for potential backdoors and security vulnerabilities....
Intel hasn't confirmed who leaked the code or where and how it was exfiltrated. However, we do know that the GitHub repository, now taken down but already replicated widely, was created by an apparent LC Future Center employee, a China-based ODM that manufactures laptops for several OEMs, including Lenovo.
Thanks to Slashdot reader Hmmmmmm for sharing the news.
"Our proprietary UEFI code appears to have been leaked by a third party. We do not believe this exposes any new security vulnerabilities as we do not rely on obfuscation of information as a security measure. This code is covered under our bug bounty program within the Project Circuit Breaker campaign, and we encourage any researchers who may identify potential vulnerabilities to bring them our attention through this program...."
The BIOS/UEFI of a computer initializes the hardware before the operating system has loaded, so among its many responsibilities, is establishing connections to certain security mechanisms, like the TPM (Trusted Platform Module). Now that the BIOS/UEFI code is in the wild and Intel has confirmed it as legitimate, both nefarious actors and security researchers alike will undoubtedly probe it to search for potential backdoors and security vulnerabilities....
Intel hasn't confirmed who leaked the code or where and how it was exfiltrated. However, we do know that the GitHub repository, now taken down but already replicated widely, was created by an apparent LC Future Center employee, a China-based ODM that manufactures laptops for several OEMs, including Lenovo.
Thanks to Slashdot reader Hmmmmmm for sharing the news.
China-based manufactures copy your IP (Score:3, Informative)
China-based manufactures copy your IP
Re: (Score:3)
"Obama is fine with it, Trump is fine with it, and Obama is still fine with it"
?? You're one of the QAnon nutters who think Biden is really Obama wearing a mask?
Name a POTUS who wasn't "fine with it" - let's see how far back you have to go to find one.
Re: (Score:3)
... Name a POTUS who wasn't "fine with it" - let's see how far back you have to go to find one.
Franklin Pierce wouldn't put up with this SH**T!!!
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
If they do it will be to aid in recycling. No company producing current gen boards will touch it, because they need to buy parts from Intel and wouldn't trust something posted to 4chan anyway.
There are some companies in China that recycle computer hardware. They remove things like Intel chipsets from old motherboards, and attach them to new ones so that older CPUs can be re-used. Particularly with server grade stuff it's often the motherboard that dies, and the Xeon CPU is still perfectly good. Also helps k
What does this mean for the opensource community? (Score:2, Interesting)
I'm wondering if this means that undervolting can be enabled again. Any other things that might be beneficial for the opensource community?
Re: (Score:3)
Usually leaks of proprietary code are quite poisonous for open source projects, so I wouldn't call any of it beneficial for the opensource community. It would be far more beneficial for all communities if Intel would make the firmware open source to begin with.
Re:What does this mean for the opensource communit (Score:5, Interesting)
It would be far more beneficial for all communities if Intel would make the firmware open source to begin with.
Unfortunately, It wouldn't do that much good if they did. With the UEFI specification came firmware update signature verification. The only way to bypass that is to manually flash the firmware chip with a hardware programmer. That assumes the chip's pins are exposed so it can be reflashed. (Because of course most PCs do not have a physical jumper to allow unauthenticated reflashing in software, like on chromebooks....) If the firmware chip is an integrated part of a SoC, you are SOL. Most people are also SOL if the machine cannot be easily taken apart without destroying the thing. (Most tablet PCs fail this one.)
Microsoft's new secured-core PC push is another hurdle. As many DRM technologies are expected to start using it, and one of the things checked is the firmware signature. Some of those DRM programs may allow you to reactivate with a custom firmware, but I'd bet money that some won't. Especially if they can check the firmware's hash directly and see it doesn't match any known vendor's public key.
Welcome to Tivo'd PCs everyone.
Re: What does this mean for the opensource communi (Score:2)
Re: (Score:2)
Yup, RISK V is the open source future, not Intel.
Especially Horse Creek [wikichip.org].
Re: (Score:2)
Oh come on, people have been saying that for the best part of 3 decades and still nothing has changed.
Microsoft has literally been trying to do it for that long. Remember Palladium? If people didn't complain, it would be implemented already.
Re: (Score:2)
Perhaps the concerns and outrage you complain about is what prevented these technologies from being misused? In a way, you seem to be cheering for more stringent computer lockdowns. Perhaps where you see a "boy who cries wolf" situation, instead it's the winning condition of people who raised concerns?
The people who warned us about a certain problem helped us avert it. Hm. Geeks as heroes. How about that.
I wonder how computer development would progress if instead of "alarmist nonsense", there was accep
Opensource: indirectly only. (Score:2)
Any other things that might be beneficial for the opensource community?
Directly? No.
Intel source code isn't licenced under terms that would allow opensource project to incorporate bits of it.
Indirectly? Perhaps.
Some motivate people could use the leaked source to document as much as possible the chipset the firmware is controlling/initialising,
and then opensource project could use the documentation to do a clean room implementation of whatever they lack as functionality.
Re: (Score:2)
Chinese wall clean-room reimpl.: Perfectly legal. (Score:5, Informative)
Such documentation would be tainted,
No, multiple jurisdictions allow reverse engineering for research purpose.
There are multiple academics across the world that can legally analyse the leak and publish their conclusion.
(Intel is even inviting them to the bug bounty for the security aspect)
as would any project that used it for the basis of their own "clean" implementation.
Again that's not how copyright law works. There are very high profile past jurisprudence in this field that exactly supports this method (the "Chinese-wall [wikipedia.org]" technique of clean-room design [wikipedia.org]):
The most prominent historical example being the documentation and clean room reimplementation of the IBM PC BIOS by Pheonix [wikipedia.org].
Except for some specific corner cases about some tiny bits of the leak (the DRM keys would probably be protected under the US' DMCA and various local jurisdictions' equivalent, and even there, there are countries that have clear exception allowing sharing DRM keys), there is no reason to think that the same separation between analysis of the leak and development from the documentation couldn't work the same way.
Re: (Score:2)
If you look at past clean room implementations you will see they were almost paranoid in the levels they go to reverse engineer someone else's code in a legal fashion - using only publicly available documentation, using publicly accessible APIs and
Re: (Score:2)
Decompiling and studying the code or tracing it with a debugger or watching the bus with a logic analyzer is reverse engineering. downloading some copyright protected sources and reading them without permission is not, it's just copyright infringement.
Copyright violation minefield (Score:3)
What a benefit to Open Source projects creating OS bootstrap code, as well as authors of drivers compliant with Intel hardware!
Re: (Score:2)
Surely it would be the other way around, Intel would have to prove they looked at it. Subpoena for all their hard drives, emails, browser history...
I think the benefit to open source may be marginal. All the stuff that is not well understood is stuff we don't want anyway, like the Management Engine and other untrustworthy parts. NICs might be the exception, although open source drivers for those are usually forthcoming anyway.
Re: (Score:3)
There might be clues in there on how to neuter the management crap, though. That would be worth a look.
I'd put money on ... (Score:3, Interesting)
Intel hasn't confirmed who leaked the code or where and how it was exfiltrated.
Re: (Score:2)
Also, as another post implied, potential poison for any competing developers.
Re: (Score:3)
Re: (Score:2)
Your bald assertions devoid of any backing or even basic reasoning ...
Dude, this is /. that's what we do ... :-)
Or are you new?
Re: (Score:3)
Intel hasn't confirmed who leaked the code or where and how it was exfiltrated.
Exceptionally unlikely. Enterprises just do not think like that and it would be impossible to keep it secret if they did.
Re: (Score:2)
Given how Intel hasn't been liable for anything else that has happened so far your conspiracy theory is a fail. A good conspiracy theory needs to have a benefit for the conspirators, and the bug bounty program is nothing new and in this case would potentially result in more pay outs since it's easier to find bugs in code than find bugs in shipped products.
who knows (Score:3)
Perhaps someone might just clean up the code a bit now!
Re: (Score:1)
No one can. The issue with BIOS/UEFI is the spec, not the code.
Re: (Score:2)
Who gives a shit about spec, Linux is entirely open source and you can flash the EEPROM with anything that will bootstrap the kernel. Do you have any idea what you could do if you didn't have to deal with 50 years of legacy garbage? For instance, imagine if you could bypass the Management Engine and get direct access to the underlying RISC core that's inside every Intel Xeon processor.
Re: (Score:2)
Who gives a shit about spec
The spec is the cause of problems / bloat with UEFI. It doesn't matter if you're god's gift to the coding world, if you have to implement trash you will write trash in the process.
Do you have any idea what you could do if you didn't have to deal with 50 years of legacy garbage?
Yes we could do a lot. But we won't because there's specs that need to be met.
For instance, imagine if you could bypass the Management Engine and get direct access to the underlying RISC core that's inside every Intel Xeon processor.
I imagine a world where unicorns still exist and I get daily blowjobs from Scarlet Johansson. But they are a fantasy as well, one that you can't simply fix through the piece of code starting the system. The hardware doesn't work like that.
Remove Management Engine (Score:3)
Now can we get rid of that Management Engine nonsense now?
Re: (Score:2)
Indeed. Almost nobody needs it. Everybody is backdoored by it.
Re: (Score:2)
No, but we may be able to get Coreboot and other alternate UEFIs to work on Intel chips which enforce the IME.
There were private keys of some kind (Score:5, Interesting)
The source code had private keys of some kind in there. Depending on what those keys were used for, that leak could be much worse than the source code.
Re: (Score:2)
That sounds like bad design to me. You sure it didn't have PUBLIC keys in it? Something like that is usually designed to be able to do code-signing-verification for things like firmware updates, to make sure the firmware hasn't been tampered with. That only requires the public key to verify the signature.
The only reason for it to have a private key is if IT is signing something. And since BIOS is probably going to be visible to the user (in a binary format), any hacker worth his salt could find that bab
Re: (Score:2)
There's simply no need for the BIOS to sign anything.
SecureBoot works off of PKI though, so there absolutely are public keys baked into the firmware.
Re: (Score:3)
Indeed. So very likely public keys, and that does _not_ endanger the secret keys. Somebody like Intel will have the secret keys in a HSM or at the very least a dedicated, not network connected system. Yes, they are incompetent, but not _that_ incompetent.
Re: (Score:3)
If that *were* the case, it would destroy the chain of trust for SecureBoot, which would be fucking terrible.
The security news platforms would be shitting their pants.
The SB PKI CA certs baked into the firmware are intended to be seen by operating systems (that's how they validate signing of any loadable kernel modules)
A disclosure of a signing key for one of those CAs would mean that SB was effectively broken for all operating systems that used it (Window
Re: (Score:3, Interesting)
There were PRIVATE keys. What itsn't still know is if those keys are for testing and tools only, or production:
https://twitter.com/_markel___... [twitter.com]
Re: (Score:2)
I find it very hard to believe Intel would give actual productive private keys to 3rd parties. Private testing keys, sure. They are not a risk.
Re: (Score:2)
Lots of public though, I'm absolutely sure they did.
So, "no new secucrity vulnerabilities", huh? (Score:4, Insightful)
Why don't I believe that. This is the ages old "cretin"-level of software security, which basically says "we have not found vulnerabilities, so nobody else can, surely". Arrogant and incompetent. About what I expect from Intel these days.
If they really cared about security, they would have a complete, current, documented, build- and installable image online at all times. It is not like some large vendor can just take and use it without permission. That would be way too obvious.
Re: (Score:2)
They do. For paying customers. What intel provides is not for an end user to use, it's for Gigabyte, MSI, Asus, etc to implement into their own code.
Re: (Score:2)
Completely worthless. It needs to be public or nobody will bother doing a security review for kudos.
Re: (Score:1)
basically says "we have not found vulnerabilities, so nobody else can, surely".
Your attempt to dumb it down to your level demonstrates why you should just read the words as they are and not try on your own interpretation of them. If they believed "nobody else can" then it wouldn't be covered by their bug bounty campaign. They don't believe there are - i.e. there are no known vulnerabilities in the code - however they leave open the possibility that there may be ones they don't know about and hence have a program that will reward people for finding and reporting them should they find a
That was a lie (Score:2, Interesting)
Uh, yes, Intel. Yes you do. Yes you totally do. You famously did it with your speculative execution bugs, which you knew you were creating because you knew you were handling that whole problem wrong, because you had been warned about it publicly literally decades ago.
The real news (Score:3)
wtf, 6 GB of code/tools for a BIOS/UFEI ? There are database software with less code that that.
I miss the days when the only purpose of the BIOS was to boot and hand control over to the OS, 64k should be enough for anyone.
Re: (Score:2)
All OF did for Macs was make add-in cards more expensive.
What I want to know (Score:3)
Early response to China ban (Score:2)
i wonder if this leak was a counter response to the ban that US has placed on china for all chips/tools/access to anything that can be used and/or for the manufacturing of artificial intelligence applications...
if we can't have the tech, then they might as well start not honor any ndas that they may have previously signed with us companies and start doing things that we probably haven't thought of... i.e. leak or purposely help their competitors.
the enemy of my enemy is my friend.