Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Intel Hardware

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.
This discussion has been archived. No new comments can be posted.

Intel Confirms Alder Lake BIOS Source Code Leaked

Comments Filter:
  • by Joe_Dragon ( 2206452 ) on Sunday October 09, 2022 @08:46PM (#62952005)

    China-based manufactures copy your IP

    • by AmiMoJo ( 196126 )

      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

  • by Anonymous Coward

    I'm wondering if this means that undervolting can be enabled again. Any other things that might be beneficial for the opensource community?

    • by caseih ( 160668 )

      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.

      • by codebase7 ( 9682010 ) on Sunday October 09, 2022 @10:30PM (#62952151)

        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.

        • Yup, RISK V is the open source future, not Intel.
    • 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.

      • by DrXym ( 126579 )
        Such documentation would be tainted, as would any project that used it for the basis of their own "clean" implementation.
        • by DrYak ( 748999 ) on Monday October 10, 2022 @05:49AM (#62952655) Homepage

          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.

          • by DrXym ( 126579 )
            This isn't reverse engineering. This is documentation written from the stolen source code. Quite different. So different in fact it would mean an instant lawsuit and would poison any project that chose to use that documentation or the source it was written from.

            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

          • 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.

  • by Tontoman ( 737489 ) on Sunday October 09, 2022 @09:12PM (#62952053)
    Obviously the source code could be somewhat disassembled from the Bios. However if the source code has Copyright notices, and if Intel was enforcing their NDAs, this might be problematic from the standpoint of persons trying to compete with Intel -- if they cannot prove they didn't view the source code
    What a benefit to Open Source projects creating OS bootstrap code, as well as authors of drivers compliant with Intel hardware!
    • by AmiMoJo ( 196126 )

      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.

      • 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)

    by fahrbot-bot ( 874524 ) on Sunday October 09, 2022 @09:16PM (#62952059)

    Intel hasn't confirmed who leaked the code or where and how it was exfiltrated.

    ... Intel "leaked" it, themselves, on purpose. Plausible deniability for any problems that arise and increased scrutiny, covered under their bug bounty program that's probably less expensive than an on-going thorough review by their developers

    • Also, as another post implied, potential poison for any competing developers.

    • Lol, sure they did. Your bald assertions devoid of any backing or even basic reasoning have really cracked this case wide open, Serpico.
      • Your bald assertions devoid of any backing or even basic reasoning ...

        Dude, this is /. that's what we do ... :-)

        Or are you new?

    • by gweihir ( 88907 )

      Intel hasn't confirmed who leaked the code or where and how it was exfiltrated.

      ... Intel "leaked" it, themselves, on purpose. Plausible deniability for any problems that arise and increased scrutiny, covered under their bug bounty program that's probably less expensive than an on-going thorough review by their developers

      Exceptionally unlikely. Enterprises just do not think like that and it would be impossible to keep it secret if they did.

    • 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.

  • by 93 Escort Wagon ( 326346 ) on Sunday October 09, 2022 @09:49PM (#62952099)

    Perhaps someone might just clean up the code a bit now!

    • No one can. The issue with BIOS/UEFI is the spec, not the code.

      • 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.

        • 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.

  • by Dwedit ( 232252 ) on Sunday October 09, 2022 @09:53PM (#62952105) Homepage

    Now can we get rid of that Management Engine nonsense now?

  • by Myria ( 562655 ) on Sunday October 09, 2022 @10:17PM (#62952135)

    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.

    • by v1 ( 525388 )

      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

      • There's just no fucking way.

        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.
        • by gweihir ( 88907 )

          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.

          • Agreed, entirely. There's just no fucking way.

            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)

            by Andor666 ( 659649 )

            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]

            • by gweihir ( 88907 )

              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.

    • Private keys? Almost certainly not.
      Lots of public though, I'm absolutely sure they did.
  • by gweihir ( 88907 ) on Monday October 10, 2022 @01:14AM (#62952323)

    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.

    • 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.

      • by gweihir ( 88907 )

        Completely worthless. It needs to be public or nobody will bother doing a security review for kudos.

    • by Anonymous Coward

      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)

    by drinkypoo ( 153816 )

    We do not believe this exposes any new security vulnerabilities as we do not rely on obfuscation of information as a security measure.

    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.

  • by jmccue ( 834797 ) on Monday October 10, 2022 @06:39AM (#62952715) Homepage

    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.

  • by hAckz0r ( 989977 ) on Monday October 10, 2022 @11:00AM (#62953429)
    Is the ME (Management Engine back door) code included?
  • 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.

/earth: file system full.

Working...