Live data from Hacker News

Intel patches new ME vulnerabilities

blog.ptsecurity.com

261–270 of 337 posts

Re: Intel patches new ME vulnerabilities

#261
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.

So, what's AMD doing these days? I'm hesitant to switch to AMD since Intel internal graphics play nicely with Linux. However that kind of doesn't matter if my machine isn't mine.

I have Ryzen 2400G which has Vega 11 internal graphics. GPU is supported only by the latest versions of graphic stack (kernel 4.17+, Mesa 18) and the only problem I have is that in Debian testing the kernel flag to enable the support of that GPU family is off, so I had to compile it myself (which could be false atm because I was away for a month and hadn't checked the updates).

Re: Intel patches new ME vulnerabilities

#262

Isn’t this vulnerability based on AMT, which is based on ME but disabled by default? Even then, every setup I’ve seen have AMT (a separate Ethernet interface) behind a firewall and is only accessible via local network. The outrage is hardly justified.

There are close to 5,000 devices exposing their Intel AMT to the Internet: https://www.shodan.io/report/j3cFHOzs

How many honeypots are there?

Re: Intel patches new ME vulnerabilities

#263

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.

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…

It might make sense only on Xeon CPUs, but consumer models like i7 are not meant for data centers.

Re: Intel patches new ME vulnerabilities

#264

Earlier quoted context omitted.

More like 5 years, or even longer, where I work. We have some 7 year old Dell servers that are still chugging along, performing their duties as well as ever.

Curious if they are managed with ME.

They have the ME and Server Platform Services (SPS) on top of that but I doubt anyone uses that to manage when Dells have DRAC/iDRAC.

Re: Intel patches new ME vulnerabilities

#265
post #63

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…

> fixing an OS-level problem remotely

If this is a problem, configure your OS better, or get a better OS. Otherwise you'll soon get need another ME on top of your ME to "fix an ME-level problem remotely".

How many layers of machines do we really need???! most datacenters already run in VMware with dockers inside running Java VM inside executing Javascript inside.

Re: Intel patches new ME vulnerabilities

#266

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.

It’s difficult to see the reason for including this on by default other than some conspiracy involving government agencies and a lot of money.

There was a submission on the weekend which posited that ME was made mandatory because of lobbying from the content industry to implement copy protection that the OS cannot tamper with (HDCP etc.).

Re: Intel patches new ME vulnerabilities

#267

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…

Depreciation determines the minimum age not the maximum. I've seen XP boxes still in use.

Yes but it's also used as a reference point for when you can upgrade. It's not the trigger but way back when YoY performance improvements were substantial companies waited for the amortization cycle to complete and jumped on the next gen. Not anymore, no point.

But the XP example you gave kind of undermines the point. Nobody should be using XP. Not even on air-gapped networks, totally cut off, with a special support contract from MS, etc. If anyone is still using it they clearly have nothing but disregard for any kind of rules (like all the XP ATMS still out there).

Re: Intel patches new ME vulnerabilities

#269

Earlier quoted context omitted.

Why is this an insurance issue? Do you expect the servers to catch on fire?

Well the distributors stamp the top of the server with a sticker that says it's safely operable for 2 years, so no one is going to insure it for more, of course. Might be European thing, though; good think for enthusiasts is that it's common to contact a company and join their next 2 years buyout and acquire cheap hardware.

I've never seen this 2 year thing in Europe. There are plenty of companies that stick to their servers for over 5 years. Some servers stay there even for more than a decade because they deliver a service using software that is no longer developed or supported, and there's no replacement for it in the company. So they keep them there, chugging along.

But with x86 being basically commodity and virtualization being used everywhere this is less of an issue in most cases. It means your VMs can mostly run on whatever metal you throw under them and that x86 metal can just be propped up to keep working for many, many years.

Re: Intel patches new ME vulnerabilities

#270

Earlier quoted context omitted.

Well the distributors stamp the top of the server with a sticker that says it's safely operable for 2 years, so no one is going to insure it for more, of course. Might be European thing, though; good think for enthusiasts is that it's common to contact a company and join their next 2 years buyout and acquire cheap hardware.

I've never seen this 2 year thing in Europe. There are plenty of companies that stick to their servers for over 5 years. Some servers stay there even for more than a decade because they deliver a service using software that is no longer developed or supported, and there's no replacement for it in the company. So they keep them there, chugging along. But with x86 being basically commodity and virtualization being used…

I consult in verticals where uptime really matters. It's not unusual though, but yes, I know that companies do this. They usually don't care about insurance/hardware SLA though. Old hardware needs to be emulated.
Post reply on HN