Announcement

Collapse
No announcement yet.

System76 Will Begin Disabling Intel ME In Their Linux Laptops

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    timofonic I think ICANN is moved to the UN jurisdiction earlier this year or last year? It's still US based entity tho, but you do not need to resolve DNS that way, you can use OpenNIC, ORSN or any other alternative ftom top level domains.

    On the topic, how "far" in the past this thing goes, I assume 2 decades at least, but is there any verifiable evidence for that?

    Comment


    • #32
      Originally posted by Espionage724 View Post

      I have unlocked InsydeH2O v5.0 firmware on my laptop currently and have a pretty clear section for being able to enable or disable ME. Not sure what it really does though; I have the HAP bit already set to disable ME.
      What did you use for that? Most tools for BIOS modding/hacking are closed source, leaks from integrator tools and/or only for Windows/DOS. UEFITool seems almost dead, unfortunately. I have an AMI OptioV bios on my MSI laptop (yes, I know their ACPI sucks...).

      Comment


      • #33
        No, the ME is not "disabled". I'm getting quite tired of corporations new to the anti-ME game jumping on this for a quick profit, largely because creating truly backdoor-free systems means moving away from x86 and it's quite expensive versus just slapping a label on a Chinese-made variant of some reference design.

        You cannot just disable the ME. The ME is an integral part of boot on Intel platforms and must be started up before the system firmware running on the main x86 cores can do its job. All these "disabling" hacks with ME Cleaner and such do is to try to disable the ME's userspace or try to shut the ME back down after boot is complete.

        However, the simple fact is the ME *still runs* on *every boot*. It's not hard to imagine malware that leverages this to insert an APT (similar to an old school TSR) into the main x86 processor while the ME is still in control during the boot process -- such malware would be pretty much invisible and, best of all, the user doesn't even know to look for it because "my vendor told me the ME was disabled".

        Still want to spend more for hardware that not only doesn't completely remove the potential backdoor, but also makes security worse by hiding the very existence of the still-active ME from the end user?
        Last edited by madscientist159; 01 December 2017, 09:16 PM.

        Comment


        • #34
          Originally posted by madscientist159 View Post
          No, the ME is not "disabled". I'm getting quite tired of corporations new to the anti-ME game jumping on this for a quick profit, largely because creating truly backdoor-free systems means moving away from x86 and it's quite expensive versus just slapping a label on a Chinese-made variant of some reference design.

          You cannot just disable the ME. The ME is an integral part of boot on Intel platforms and must be started up before the system firmware running on the main x86 cores can do its job. All these "disabling" hacks with ME Cleaner and such do is to try to disable the ME's userspace or try to shut the ME back down after boot is complete.

          However, the simple fact is the ME *still runs* on *every boot*. It's not hard to imagine malware that leverages this to insert an APT (similar to an old school TSR) into the main x86 processor while the ME is still in control during the boot process -- such malware would be pretty much invisible and, best of all, the user doesn't even know to look for it because "my vendor told me the ME was disabled".

          Still want to spend more for hardware that not only doesn't completely remove the potential backdoor, but also makes security worse by hiding the very existence of the still-active ME from the end user?
          You made me think of something: Do you remember about "fighting fire with fire" (or something similar, I'm tired and my English get worse)?

          I think the best solution to make technologies like Intel's ME and AMD's PSP is to show them in practical form how dangerous they can be. The interested parties to provoke these technologies become totally unpopular in all sectors must develop Open Source malware for them! Of course, all in a didactical exercise but show all the possible risks without hiding anything in the implementations.

          If this get widespread and it becomes easy for even an script kiddie to make use of it: I'm sure many involved parties in stuff like ME and PSP will reconsider different ways unlike actual situation, including both Intel and AMD but not limited only to them.

          Comment


          • #35
            Originally posted by timofonic View Post
            What did you use for that? Most tools for BIOS modding/hacking are closed source, leaks from integrator tools and/or only for Windows/DOS. UEFITool seems almost dead, unfortunately. I have an AMI OptioV bios on my MSI laptop (yes, I know their ACPI sucks...).
            Afaik bios modding (on laptops) died in 2015 or something when most UEFI firmwares became signed, so while you could still technically mod them, they won't boot because of signature mismatch.

            So far only the me_cleaner can work on modern-ish laptops as the ME regions in flash memory are not handled by the UEFI so it does not care if you butcher them (as long as ME itself is fine with it) or change the ME config to add the "ME disable option" that was added for the HAP certification program (and found by some reverse-engineering).

            Comment


            • #36
              Originally posted by madscientist159 View Post
              No, the ME is not "disabled".
              It's close enough to "disabled" to be fair to claim it.
              They are using the HAP bit, which shuts down ME even before it tries to load its modules.

              With that bit set the only thing ME does is low-level initialization without any access to outside world, then shuts down.

              slapping a label on a Chinese-made variant of some reference design.
              They are branding Clevo laptops. Clevo is a bigass OEM/ODM making laptops also for Dell, HP, MSI/Gigabyte gaming laptops, Sager and other brands of gaming laptops, and others like pcspecialist.co.uk.
              They are from Taiwan, and their products are good quality hardware-wise.

              However, the simple fact is the ME *still runs* on *every boot*.
              It's not "boot", it is "very early hardware initialization phase", before even UEFI is loaded and executed.

              The attack surface is extremely tiny now, as ME with that option is nothing more than a bootROM.

              The big issue of ME is when it is live after boot. If you want to pwn a x86 system at firmware level the UEFI firmware is the only thing you will need to target anyway.

              best of all, the user doesn't even know to look for it because "my vendor told me the ME was disabled".
              FYI: no user knows how to look for board-firmware-grade malware anyway, because none has ever signed NDAs or is a badass hacker reverse-engineering stuff.

              Still want to spend more for hardware that not only doesn't completely remove the potential backdoor, but also makes security worse by hiding the very existence of the still-active ME from the end user?
              You're blowing this well beyond its actual proportions.

              ME is effectively disabled and reduced to low-level bootROM that runs for a few seconds before even friggin UEFI is up, and has no kind of access to any peripheral.

              Security is increased by a substantial amount, and this adds value to an otherwise normal Clevo laptop with Linux preinstalled.

              Because disabling the ME yourself is a bit involved process requiring hardware flashing tools and some electronic experience, plus usually dismantling the whole damn thing because the SPI chip is not accessible from user-removable panels.

              Comment


              • #37
                Originally posted by starshipeleven View Post
                FYI: no user knows how to look for board-firmware-grade malware anyway, because none has ever signed NDAs or is a badass hacker reverse-engineering stuff.
                If the "disabled" ME wasn't being incorrectly reported, I would argue that the news did a good job of letting people know that they *do* have to look for board-level malware.

                Originally posted by starshipeleven View Post
                You're blowing this well beyond its actual proportions.

                ME is effectively disabled and reduced to low-level bootROM that runs for a few seconds before even friggin UEFI is up, and has no kind of access to any peripheral.
                It has full access to the x86 cores, the UEFI firmware, everything during that boot process. So it can alter the behaviour of the system in a manner that will persist all the way until machine shutdown with relative ease. This is not concerning to you?

                Originally posted by starshipeleven View Post
                Security is increased by a substantial amount, and this adds value to an otherwise normal Clevo laptop with Linux preinstalled.
                That's great. Call it what it is -- a "limited" ME. That's safe, accurate, and honest, but I imagine it doesn't sell as many systems. See the problem?

                Comment


                • #38
                  Originally posted by madscientist159 View Post
                  No, the ME is not "disabled". I'm getting quite tired of corporations new to the anti-ME game jumping on this for a quick profit, largely because creating truly backdoor-free systems means moving away from x86 and it's quite expensive versus just slapping a label on a Chinese-made variant of some reference design.

                  You cannot just disable the ME. The ME is an integral part of boot on Intel platforms and must be started up before the system firmware running on the main x86 cores can do its job. All these "disabling" hacks with ME Cleaner and such do is to try to disable the ME's userspace or try to shut the ME back down after boot is complete.

                  However, the simple fact is the ME *still runs* on *every boot*. It's not hard to imagine malware that leverages this to insert an APT (similar to an old school TSR) into the main x86 processor while the ME is still in control during the boot process -- such malware would be pretty much invisible and, best of all, the user doesn't even know to look for it because "my vendor told me the ME was disabled".

                  Still want to spend more for hardware that not only doesn't completely remove the potential backdoor, but also makes security worse by hiding the very existence of the still-active ME from the end user?
                  Read up on github wiki on how me_cleaner actually works and stop repeating credibly sounding bullshit that will gets further repeated by misinformed people. Also it's perfectly possible for "board manufacturers" (MSI, Asus, ...) to disable all ME code in the chipset, they are literally the ones who implemented it (Intel merely provides reference implementation that third party manufacturers can screw up or reuse). System76 or Dell can at best put some pressure on them to disable this or abuse HAP disable bit made for the CIA (because CIA actually can pressure manufacturers into compliance unlike popular demand or whining users on reddit/forums).

                  As far as your open hardware argument goes, I reluctantly agree that we don't have anything powerful enough for modern tasks and open.
                  Feel free to start a kickstarter campaign, raise few hundred millions of dollars and then implement your own chip. Result will be an implementation that we have no way of verifying, unless you can manage to pay few hundred million dolars for a fab to produce your own chip which other people will not be able to verify. In the end its about trust and modern open hardware processors are a pipe dream.

                  Also, it's not impossible to verify that HAP bit functionality of me_cleaner works properly, all you have to do is modify source code slightly with "halt and catch fire" instructions in regions that it affects, set HAP bit to disable ME. If you manage to brick your system then HAP bit doesn't work, if it continues in spite of bunch of garbage in ME memory then it does indeed work as intended.
                  Last edited by Guest; 04 December 2017, 12:58 PM.

                  Comment

                  Working...
                  X