Intel patches new ME vulnerabilities • Hacker News Board

Re: Intel patches new ME vulnerabilities

#151

Post by woodson » Sun, Jul 22, 2018, 5:05 PM UTC

zorkw4rg wrote: post #149

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.

Maybe someone could clarify some things, because I think the impression that I got from reading about this vulnerability is completely wrong. Isn't vPro just something in server hardware? At least the CPU, Mainboard and NIC all need to be certified/from Intel to support this? You could get the impression that every single computer with a Intel CPU is vulnerable to be hacked over the network. Which I really doubt. > I…

> Isn't vPro just something in server hardware?

It’s in most business notebooks (HP, Dell, Lenovo, etc.)

Re: Intel patches new ME vulnerabilities

#152

Post by arnaudsm » Sun, Jul 22, 2018, 5:08 PM UTC

I'm surprised by the lack of media coverage: Intel is deliberately leaving billions of CPUs vulnerable.

For a $200 billion company, refusing to spend some ressources to patch all generations is irresponsible.

Think of how many governments still use <2012 CPUs.

Re: Intel patches new ME vulnerabilities

#153

Post by woolvalley » Sun, Jul 22, 2018, 5:14 PM UTC

brudgers wrote: post #108

rectang wrote: post #90

Earlier quoted context omitted.

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 fo…

If something is considered broken before the full 5 years and you throw it away, you can deduct the rest of the cost right away correct?

Re: Intel patches new ME vulnerabilities

#154

Post by PeCaN » Sun, Jul 22, 2018, 5:22 PM UTC

close04 wrote: post #40

avuton wrote: post #15

Earlier quoted context omitted.

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

"Luckily" most old Atoms will never get mitigations for Meltdown/Spectre :). So if you're using an Intel CPU today you'll just have to pick your poison.

Luckily, most old Atoms are really simple in-order processors that aren't vulnerable to Meltdown/Spectre.

Re: Intel patches new ME vulnerabilities

#155

Post by close04 » Sun, Jul 22, 2018, 5:28 PM UTC

yborg wrote: post #144

close04 wrote: post #94

Earlier quoted context omitted.

As far as I know while the Management Engine is in all chipsets that accompany Intel CPUs, Apple never shipped any AMT enabled firmware. This is the more exposed component.

Apple is exposed to ME bugs. https://support.apple.com/en-us/HT208465 See the "EFI" section.

The ME is most definitely there but AMT is not. And AMT is the one with far more exposed security flaws that can be exploited over the network by virtue of AMT's purpose. Like the ones detailed in the article here. Otherwise without a shadow of doubt the ME is present in every Intel chipset since 2006.

Exploiting the ME is possible even without AMT but it definitely raises the bar in the sophistication of the attack.

The me_cleaner tool might do a good job in disabling the ME in most cases but since it's doing it by removing components from the ME FW it probably doesn't work with every OEM implementation.

Re: Intel patches new ME vulnerabilities

#156

Post by PeCaN » Sun, Jul 22, 2018, 5:28 PM UTC

scruffyherder wrote: post #135

nine_k wrote: post #54

Earlier quoted context omitted.

I heard Google spends a lot of money and effort to (slowly) move to Power9. It does have a management processor but it's open for inspection and modification. Maybe other cloud providers, and/or private clouds, would consider that.

Source on that? I'd love to use that as a prodding stick to shove all my java/node stuff off of x86..

Google Confirms POWER9 Processor Data Center Deployment At OpenPOWER Summit 2018 https://www.forbes.com/sites/patrickmoorhead/2018/03/19/head...

IBM Begins Power9 Rollout with Backing from DOE, Google https://www.hpcwire.com/2017/12/06/ibm-begins-power9-rollout...

Google's Data Centers Now Have IBM Inside https://www.fool.com/investing/2018/03/22/googles-data-cente...

Introducing Zaius, Google and Rackspace’s open server running IBM POWER9 https://cloudplatform.googleblog.com/2016/10/introducing-Zai...

They're also a platinum-level member of the OpenPOWER consortium (i.e. they have a position on the board of directors).

Re: Intel patches new ME vulnerabilities

#157

Post by PeCaN » Sun, Jul 22, 2018, 5:31 PM UTC

rhencke wrote: post #18

ganzuul wrote: post #13

My CPU has an HTTP server? But why?

Your CPU actually runs its own entire, separate operating system - MINIX. https://www.cs.vu.nl/~ast/intel/

IIRC for many generations it was ThreadX, which is a proprietary RTOS.

Re: Intel patches new ME vulnerabilities

#158

Post by zzzcpan » Sun, Jul 22, 2018, 5:33 PM UTC

close04 wrote: post #68

avuton wrote: post #46

Earlier quoted context omitted.

I was under the impression that they weren't susceptible.

There's a non-exhaustive list here: https://www.intel.com/content/www/us/en/security-center/advi... Intel® Atom™ Processor C Series Intel® Atom™ Processor E Series Intel® Atom™ Processor A Series Intel® Atom™ Processor x3 Series Intel® Atom™ Processor Z Series This being said, this is the current status for my old Atom N270 (2008): https://imgur.com/a/pbeJ306 Unless the tool is wrong, but I think it was generally mar…

Tools usually just check CPUID and system configuration and don't actually test vulnerabilities. And not necessarily interpreting everything correctly. You can do that without running anything, just checking your OS updates and whether your CPU is out-of-order one, i.e. with speculative execution. N270 isn't and therefore isn't vulnerable.

If you want to truly test speculative vulnerabilities, compile this program: https://github.com/Eugnis/spectre-attack (EDIT: although this one probably won't work on N270, since it uses rdtscp, that it doesn't have, need to find version with just rdtsc)

Re: Intel patches new ME vulnerabilities

#159

Post by PeCaN » Sun, Jul 22, 2018, 5:33 PM UTC

throwaway2048 wrote: post #141

turblety wrote: post #82

Earlier quoted context omitted.

Finally? That ME thing should be nowhere near private and confidential data. There's constantly bugs being found in it [1][2]. Honestly if you are a large company, organisation, government, etc and you are using Intel or AMD products, then you are being very irresponsible. There is no excuse, enough information is out there that even a non-technical CTO should know better. 1. https://www.wired.com/story/intel-managem…

There is quite literally no viable alternative to x86 for 95% (more like 99.9%, but I am being generous) of the server and workstation market. Pretending like there is and anyone choosing x86 is irresponsible is just being a smug fool.

POWER is actually competitive on price/performance now.

Re: Intel patches new ME vulnerabilities

#160

Post by vengefulduck » Sun, Jul 22, 2018, 5:41 PM UTC

hlandau wrote: post #146

Kliment wrote: post #132

Earlier quoted context omitted.

This is correct but misleading. The me_cleaner approach, with all options, wipes the entirety of the ME firmware except the module needed for hardware bringup. It then causes the ME to crash as soon as hardware bringup has happened. The host system cannot communicate with the ME processor and the ME processor does not execute any further code after this point. This is the current gold standard. The next stage would b…

How can the functionality be implemented independently when the modules must be signed? Complete reverse engineering could at least serve as an effective audit though.

It seems likely, to me anyway, that the CPU doesn't have any effective way of verifing what is running on the ME. So reversed firmware could just lie to the CPU and tell it that its firmware is signed when it isn't. A similar approch is use the microg project to replace proprietary google play services by spoofing google's signature.