Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Intel patches new ME vulnerabilities

blog.ptsecurity.com

Post reply on HN
Print view View original

221–230 of 337 posts

Re: Intel patches new ME vulnerabilities

#221

Post by TomMarius »

emsy wrote: post #186
blitmap wrote: post #182

Earlier quoted context omitted.

As I understand it, ME is used to remotely control the processor like in a datacenter. If a datacenter is buying hundreds of thousands of these it makes sense to have it on by default so their people don't have to go in and turn anything on. As much as I recognize it as a vulnerability (to the extreme), it doesn't make sense to have it off by default. They should certainly support a way to _permanently_ disable it. I…

Their motivations are irrelevant. Consumers aren't datacenters.

You know that companies deploy these processors as well, right? I just finished a deployment of 10k Intel i5 machines.

Re: Intel patches new ME vulnerabilities

#222

Post by praseodym »

close04 wrote: post #89
nine_k wrote: post #64

Earlier quoted context omitted.

Does this mean that if you configure ME in your BIOS in a certain way, it is not exposed to the network? It sounds almost too good to be true: the attack surface is removed by a BIOS switch?

No, it means that AMT is not exposed to the internet . The ME itself is not exposed, but the AMT running on top of it is designed to be accessed over the network. Unless you explicitly expose AMT to the internet you are relatively safe as long as your local network isn't compromised. So it can be exploited only by an attacker with physical access or at least in the same network. Shodan wouldn't show you any of these…

In a typical home network “any device on the same network” is a very large attack vector. You just need some unsecured webcam, router or other cheap IoT device; the Mirai botnet proves that those are widely deployed.

Re: Intel patches new ME vulnerabilities

#224

Post by alexandercrohde »

nine_k wrote: post #63
deathhand wrote: post #4

Do we really need remote code execution on the bios level? Is this a case of 'we can, but should we?'

Think about managing tens of thousands of server in a datacenter. An ability to do everything you can do form a local console (and preferably more), without physical access or a KV switch, is very important. Remotely managing a corporate desktop or laptop, e.g. fixing an OS-level problem remotely, may also be important. OTOH I'd prefer this functionality clearly delineated, usinf strong encryption, and with an explic…

Frankly, I don't give a fuck about datacenters. I'd rather pay $100 more and NOT have remote functionality in my hardware.

There is no universe where what we have now is a good solution. There is no universe where there aren't superior alternatives (like custom bios for datacenter users, like just spending a little bit more money and having two versions)

Re: Intel patches new ME vulnerabilities

#225

Post by monocasa »

solarkraft wrote: post #219
monocasa wrote: post #212

Earlier quoted context omitted.

You do use it. AFAIK, the ME handles power management, legacy backwards compatibility, and all sorts of other random chipset stuff you don't necessarily want to expose to the main cores, in addition to the DRM and remote administration capabilities.

But why can't I disable the remote administration capabilities?

You can. It's disabled on any non vpro system. It takes two exploits on a non vpro system to exploit the ME remotely: the first exploit running on the main cores to reenable the remote administration, and the exploits listed here for once it's enabled.

Re: Intel patches new ME vulnerabilities

#226

Post by ebikelaw »

TomMarius wrote: post #220
ebikelaw wrote: post #168

Earlier quoted context omitted.

This is not in accordance with my experience. The life of an Intel platform in a datacenter is more like 7-10 years.

What insurance comapny insures that? What company offers SLAs like that? I want in on that deal!

I have no idea since I'm not in the finance department. Start up an AWS m1.small instance and see what kind of CPU you're using. You may be surprised.

Even AWS's current mainstream "M4" offering is using a CPU from 4 years ago.

Re: Intel patches new ME vulnerabilities

#227

Post by ta45737272742 »

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.

Agreed; none of this even passes the smell test to me, it seems absurd to bundle this level of functionality and not have a big warning on the can: "You are not really in control of your machine, at all."

I wouldn't have purchased my last Intel chip with better knowledge of this junk side-loaded, full-access, completely-opaque OS, made by a company incredibly thick with our mates in the 5 Eyes etc.

Re: Intel patches new ME vulnerabilities

#228

Post by TomMarius »

ebikelaw wrote: post #226
TomMarius wrote: post #220

Earlier quoted context omitted.

What insurance comapny insures that? What company offers SLAs like that? I want in on that deal!

I have no idea since I'm not in the finance department. Start up an AWS m1.small instance and see what kind of CPU you're using. You may be surprised. Even AWS's current mainstream "M4" offering is using a CPU from 4 years ago.

Yeah I guess that AWS gets these deals, maybe even supports it themselves. We others don't/can't (no, AWS is not an option). :-(

Re: Intel patches new ME vulnerabilities

#229

Post by rubatuga »

kawsper wrote: post #32
ipsin wrote: post #20

Has Intel offered an official "disable ME" patch? I'd like to close the door once and not worry about it again.

There are no official ways of disabling the ME. The Coreboot project and the Hardenedlinux project have worked on it, and here are some resources on their progress: https://hardenedlinux.github.io/firmware/2016/11/17/neutrali... https://www.coreboot.org/Intel_Management_Engine And here is a general writeup on the Intel chips and their "features": https://libreboot.org/faq.html#intel If Intel aren't going to patch old…

For those who need a step by step tutorial for using me_cleaner with the Raspberry Pi, check out my easy video guide, which assumes no background knowledge.

https://youtu.be/aRUxfxp9dJ8

Re: Intel patches new ME vulnerabilities

#230

Post by samstave »

ec109685 wrote: post #119
brudgers wrote: post #108

Earlier quoted context omitted.

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…

Do you have any citations that companies are replacing their intel processors every 2 years? That is not inline with what I have seen.

extrapolate as you will...

https://aws.amazon.com/blogs/aws/ec2-instance-history/

    I didn’t have one, but it seemed like a worthwhile thing to have and so I spent a few minutes putting the following list together (these are all announcement dates):
August 2006 – m1.small.

October 2007 – m1.large, m1.xlarge.

May 2008 – c1.medium, c1.xlarge.

October 2009 – m2.2xlarge, m2.4xlarge.

February 2010 – m2.xlarge.

July 2010 – cc1.4xlarge.

September 2010 – t1.micro.

November 2010 – cg1.4xlarge.

November 2011 – cc2.8xlarge.

March 2012 – m1.medium.

July 2012 – hi1.4xlarge.

October 2012 – m3.xlarge, m3.2xlarge.

December 2012 – hs1.8xlarge.

January 2013 – cr1.8xlarge.

November 2013 – c3.large, c3.xlarge, c3.2xlarge, c3.4xlarge, c3.8xlarge.

November 2013 – g2.2xlarge.

December 2013 – i2.xlarge, i2.2xlarge, i2.4xlarge, i2.8xlarge.

January 2014 – m3.medium, m3.large.

April 2014 – r3.large, r3.xlarge, r3.2xlarge, r3.4xlarge, r3.8xlarge.

July 2014 – t2.micro, t2.small, t2.medium.

January 2015 – c4.large, c4.xlarge, c4.2xlarge, c4.4xlarge, c4.8xlarge.

March 2015 – d2.xlarge, d2.2xlarge, d2.4xlarge, d2.8xlarge.

April 2015 – g2.8xlarge.

June 2015 – t2.large.

June 2015 – m4.large, m4.xlarge, m4.2xlarge, m4.4xlarge, m4.10xlarge.

December 2015 – t2.nano.

May 2016 – x1.32xlarge.

September 2016 – m4.16xlarge.

September 2016 – p2.xlarge, p2.8xlarge, p2.16xlarge. October 2016 – x1.16xlarge.

November 2016 – f1.2xlarge, f1.16xlarge.

November 2016 – r4.large, r4.xlarge, r4.2xlarge, r4.4xlarge, r4.8xlarge, r4.16xlarge.

November 2016 – t2.xlarge, t2.2xlarge.

November 2016 – i3.large, i3.xlarge, i3.2xlarge, i3.4xlarge, i3.8xlarge, i3.16xlarge.

November 2016 – c5.large, c5.xlarge, c5.2xlarge, c5.4xlarge, c5.8xlarge, c5.16xlarge.

July 2017 – g3.4xlarge, g3.8xlarge, g3.16xlarge. September 2017 – x1e.32xlarge.

October 2017 – p3.2xlarge, p3.8xlarge, p3.16xlarge.

November 2017 – x1e.xlarge, x1e.2xlarge, x1e.4xlarge, x1e.8xlarge, x1e.16xlarge.

November 2017 – m5.large, m5.xlarge, m5.2xlarge, m5.4xlarge, m5.12xlarge, m5.24xlarge.

November 2017 – h1.2xlarge, h1.4xlarge, h1.8xlarge, h1.16xlarge.

November 2017 – i3.metal.

June 2018 – m5d.large, m5d.xlarge, m5d.2xlarge, m5d.4xlarge, m5d.12xlarge, m5d.24xlarge.

July 2018 – z1d.large, z1d.xlarge, z1d.2xlarge, z1d.3xlarge, z1d.6xlarge, z1d.12xlarge, z1d.metal, r5.large, r5.xlarge, r5.2xlarge, r5.4xlarge, r5.12xlarge, r5.metal, r5.24xlarge, r5d.large, r5d.xlarge, r5d.2xlarge, r5d.4xlarge, r5d.12xlarge, r5d.24xlarge, r5d.metal.

Post reply on HN