Intel patches new ME vulnerabilities • Hacker News Board

Re: Intel patches new ME vulnerabilities

#101

Post by nine_k » Sun, Jul 22, 2018, 3:24 PM UTC

As far as I could find out from Intel AMT docs [1], remotely accessible AMT requires an AMT-enabled network adapter.

I suppose built-in adapters of Intel chipsets have this feature (at least if marked as vPro).

This means that there's a quite decent chance that your not Intel-branded PCI-Expess NIC is NOT AMT-enabled. Most likely your USB-attached WiFi adapter is also inaccessible to AMT.

This, if correct, means that your home machine, or your laptop, can be protected from this or any future remotely-activated AMT vulnerabilities by disabling the built-in NICs in BIOS, and using a third-party NIC, either for wired or wireless communication.

(For a server fleet, it's different, but you likely don't want to lose AMT remote access if you have a few racks full of servers anyway.)

[1]: https://software.intel.com/en-us/articles/getting-started-wi...

Re: Intel patches new ME vulnerabilities

#102

Post by glasz » Sun, Jul 22, 2018, 3:27 PM UTC

thepumpkin1979 wrote: post #47

Can MacBook owners do something to disable or cripple Intel ME? Is Apple disabling it for us? I can’t find Apple responses to these issues.

i have been told somewhere on the scary internet that the nature and architecture of a mac makes the ME dysfunctional because everything else is apple-made. custom chipsets and so on.

Re: Intel patches new ME vulnerabilities

#103

Post by close04 » Sun, Jul 22, 2018, 3:30 PM UTC

nine_k wrote: post #101

As far as I could find out from Intel AMT docs [1], remotely accessible AMT requires an AMT-enabled network adapter. I suppose built-in adapters of Intel chipsets have this feature (at least if marked as vPro). This means that there's a quite decent chance that your not Intel-branded PCI-Expess NIC is NOT AMT-enabled. Most likely your USB-attached WiFi adapter is also inaccessible to AMT. This, if correct, means that…

Unless your machine is branded as vPro it most likely means that it simply lacks the FW part to run AMT. So it will have the ME in the chipset, it might as well have the correct CPU and NIC for vPro (usually the NICs with M for management in the model name), but it's missing the firmware.

Outside of OEM machines the only time I managed to build a vPro enabled system was in Haswell times when Intel had desktop motherboards with the correct chipset and NIC combination, and the BIOS to run it. Right around that time Intel exited the motherboard business and most manufacturers don't bother with shipping the firmware anyway.

Re: Intel patches new ME vulnerabilities

#104

Post by ekianjo » Sun, Jul 22, 2018, 3:30 PM UTC

Filligree wrote: post #50

avuton wrote: post #15

Earlier quoted context omitted.

I'm oddly lucky that I based my fanless server off an old Atom platform.

AMD seems considerably more on top of the security game. As for ME, make sure you avoid any system on which it is enabled.

That's just because AMD is the underdog and it not as well studied as Intel. Given the same scrutiny I'd wage it would be as bad as Intel.

Re: Intel patches new ME vulnerabilities

#105

Post by inawarminister » Sun, Jul 22, 2018, 3:31 PM UTC

std_throwaway wrote: post #97

inawarminister wrote: post #69

Earlier quoted context omitted.

I thought you can in C2D (Nehalem?) era ThinkPads? https://libreboot.org/ and you can minimize ME in Sandy and Ivy Bridge, using ME_Cleaner? edit: according to sounds' comment* in HN (2016), The ME is purportedly placed in "recovery" mode [*] https://news.ycombinator.com/item?id=13056997

Is that an official tool supported by intel?

No, it's a reverse engineer by the open source community AFAIK.

But very stable, I am looking to flash my X220 soon for what it's worth.

Re: Intel patches new ME vulnerabilities

#106

Post by 21 » Sun, Jul 22, 2018, 3:34 PM UTC

rectang wrote: post #25

Macha wrote: post #3

Earlier quoted context omitted.

Also worth noting that they're not patching it for 1st, 2nd or 3rd generation Core CPUs. I'm sure there's plenty of Sandy Bridge/Ivy Bridge CPUs in the wild, and it's not like you have an option to discontinue use of the Intel ME :(

Planned obsolescence of otherwise viable product implemented via a certain-to-be-exploited architecture (the ME) followed by strategic withholding of patches?

That's quite a conspiracy theory you got there. Things like these make people look at AMD again.

Re: Intel patches new ME vulnerabilities

#107

Post by jerheinze » Sun, Jul 22, 2018, 3:35 PM UTC

inawarminister wrote: post #69

jerheinze wrote: post #60

Earlier quoted context omitted.

You can't disable ME.

I thought you can in C2D (Nehalem?) era ThinkPads? https://libreboot.org/ and you can minimize ME in Sandy and Ivy Bridge, using ME_Cleaner? edit: according to sounds' comment* in HN (2016), The ME is purportedly placed in "recovery" mode [*] https://news.ycombinator.com/item?id=13056997

Minimize != Disable.

Re: Intel patches new ME vulnerabilities

#108

Post by brudgers » Sun, Jul 22, 2018, 3:37 PM UTC

rectang wrote: post #90

std_throwaway wrote: post #72

I don't want a patch. I don't use that thing for anything. I want them to disable that thing by default! Leaving those backdoors open in older products should lead to a recall because the flaw was there all along.

Certainly if the lifespan of Intel chips turns out to be much shorter than the marketplace expected (because Intel is unable to provide security updates), that affects the value of Intel products and ought to inform future buying decisions. Whether it is the unfortunate materialization of Spectre-style bugs or the deliberately insecure-by-design ME, Intel's inability to support its products is dismaying.

The ordinary life cycle of an Intel CPU is the five t̶h̶r̶e̶e̶ year depreciation schedule in the US tax system. The life cycle for Intel's most important customers is less and is based on operating cost in large data centers and these are driven by density, throughput, and energy utilization. Traditionally this has been two years or less as reflected in Intel's tick-tock iteration strategy. The critical life cycle for Intel is not consumer/SMB sales which don't generate sales frequencies and volumes of leading edge products.

Re: Intel patches new ME vulnerabilities

#109

Post by 21 » Sun, Jul 22, 2018, 3:37 PM UTC

exikyut wrote: post #41

nh2 wrote: post #2

Intel advisory: https://www.intel.com/content/www/us/en/security-center/advi... CVE-2018-3628 - "Buffer overflow in HTTP handler" Affected processor list (simplified reordered by me to reflect relevance and improve readability): • Core i3/i5/i7, generation 1-8 (that is, all of them) • Xeon E3-1200 v5/v6 • Xeon Scalable • Xeon W • Core 2 Duo vPro, Centrino 2 vPro

Wow. The Web really has won. We have HTTP parsing failures in our CPUs .

I'm waiting for the day where Node.js runs inside the CPU, downloads NPM packages, and then a left-pad happens. Mark my words.

Re: Intel patches new ME vulnerabilities

#110

Post by keyme » Sun, Jul 22, 2018, 3:41 PM UTC

iknowverylittle wrote: post #58

>CVE-2018-3628, Intel says that exploitation is possible only from the same subnet So if I understand correctly, at the moment, these CPUs are vulnerable on a local network but not currently over the internet? Fortunately then various groups have already been working to remove and nullify as much of ME as possible.

"... only from the same subnet"

What about DNS rebinding (decade old unpached vuln)? It allows websites to issue requests onto your local subnet.

Actually... Issuing a request doesn't even require any vuln, it's not a SOP violation...