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

291–300 of 337 posts

Re: Intel patches new ME vulnerabilities

#291

Post by BanazirGalbasi »

casefields wrote: post #241
confounded wrote: post #233

Just a note that if you want to avoid Intel's disastrous Management Engine, there are companies you can support that disable it. Purism[0] sell nice MBP-style, Debian-based laptops with modern Intel processors with the NSA's 'High Assurance Platform' bit set, and as much of the ME code removed as possible. It still runs briefly at boot, but this is the most-disabled you can currently get on any i3/i5/i7 processor[1].…

Never heard of these. Thanks for the pointer.

System76 is probably the most well-known Linux laptop distributor in the US, their offerings are pretty popular. I know a few people with one of their laptops and all of them are pretty satisfied.

Purism is a bit more "extreme", trying to create an all-libre laptop that avoids proprietary software and hardware. Once their equipment is a bit more stable it's something I'm going to look into more, for now they're still in development though.

Re: Intel patches new ME vulnerabilities

#292

Post by dsfyu404ed »

close04 wrote: post #267
lowbloodsugar wrote: post #253

Earlier quoted context omitted.

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…

>Nobody should be using XP. Not even on air-gapped networks, totally cut off, with a special support contract from MS, etc.

I think you're severely over-estimating the criticality of stuff that's still running XP. It's mostly used for antiquated industrial hardware that gets used 5x a year, maybe (old CNC mills and whatnot), often times with no network. If it gets crypotwalled via flash-drive then someone will reinstall it and carry on with life.

Re: Intel patches new ME vulnerabilities

#293

Post by ajross »

exikyut wrote: post #285
ajross wrote: post #216

Earlier quoted context omitted.

Sure, but that's " in our CPUs " in, kinda, exactly the same way that nginx is. It's a microcontroller. It's not like the hardware implemented an HTTP server.

If I just swap the paragraphs in your comment, > It's not like the hardware implemented an HTTP server. But yes, yes yes it is. I don't mean "in our CPUs" in the sense of running nginx. I say "in our CPUs" because - the Web server is physically inside the CPU die - you can't remove or change it thanks to code signing, so (to me) it's truly wedged in there In effect, it's as hardcoded as the electrical circuitry and t…

> - the Web server is physically inside the CPU die

It's loaded from external storage, and probably runs in external DRAM.

> - you can't remove or change it thanks to code signing, so (to me) it's truly wedged in there

They literally just did, that's what the linked article is about.

> In effect, it's as hardcoded as the electrical circuitry and the transistors are.

If your criteria for hyperbole is the inability of the user to make modifications, then every effective DRM strategy is "as hardcoded as the electrical circuitry and transistors" also.

That's silly. It's a CPU. It runs software. It speaks to devices with drivers. There's no technical meat to your argument.

Re: Intel patches new ME vulnerabilities

#294

Post by deno »

pjmlp wrote: post #284
deno wrote: post #277

Earlier quoted context omitted.

FWIW, it’s a completely different architecture. GCN has support all the way down to 1.0. The graphics card in your EEE PC is upgradable, if you’re feeling adventurous[1]. [1] https://www.ifixit.com/Guide/Asus+Eee+PC+1008ha+Graphics+Car...

I know, and this kind of attitude regarding drivers is what as graphics oriented person, eventually pushed me back into the Windows/OS X world. The graphics card was working perfectly fine before they decided to reboot driver support. Now with the legacy driver I have to force enable acceleration and even then I sometimes get the feeling it isn't really working, given how the fan behaves when watching movies on the g…

> Now with the legacy driver I have to force enable acceleration and even then I sometimes get the feeling it isn't really working, given how the fan behaves when watching movies on the go.

If you want zero-copy video playback for optimizing battery life use mpv with --hwdec=vaapi. Or vdpau or whatever API is supported with that driver. You can also try switching -vo to vdpau/vaapi from OpenGL.

> I know, and this kind of attitude regarding drivers is what as graphics oriented person, eventually pushed me back into the Windows/OS X world.

On Windows you get legacy drivers for older architectures as well. Also the case with NVIDIA. It’s legacy hardware, after all… AMD’s new driver is completely open source, but it targets GCN, which is a completely different type of hardware.

Re: Intel patches new ME vulnerabilities

#295

Post by gnufx »

zamadatix wrote: post #115
close04 wrote: post #79

Earlier quoted context omitted.

And it's exactly what the CVEs are about, isn't it? From the article: vulnerability enables full-blown remote code execution in the AMT process of the Management Engine. From Intel: https://www.intel.com/content/www/us/en/security-center/advi... Buffer overflow in HTTP handler in Intel® Active Management Technology in Intel Converged Security Manageability Engine

Yes, it's what the CVEs are about, but the whole comment thread has been riddled with people talking past one another creating confusion: - The CVEs are about AMT portion only not the base IME - Not all affected hardware will be patched (based on age) - AMT can be disabled (and is by default) - IME/AMT run on a croprocessor on the motherboard - not the CPU itself - AMT runs an HTTP server for IPMI abilities

> - AMT runs an HTTP server for IPMI abilities

IPMI doesn't use HTTP.

AMT/vPro is apparently not for servers, and likely operates on the system NIC. The first rule of out-of-band management interfaces should be "use a physically-separate interface", which is unfortunately frequently broken (by one vendor when the procurement specified a separate interface).

Re: Intel patches new ME vulnerabilities

#296

Post by Aissen »

nine_k wrote: post #54
dsabanin wrote: post #19

Finally it happened. Here's to hoping that after being exposed to this kind of risk, enterprises and regular customers start being more inquisitive about what code gets embedded into their hardware and why.

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.

I'd bet that Google has probably 10x more engineers working on improving the situation with their various Intel chipsets (being on laptops, or servers), than those working on "Plan B" (Power9), or "Plan C" (RISC-V) solutions.

Re: Intel patches new ME vulnerabilities

#297

Post by orblivion »

rectang wrote: post #78
orblivion wrote: post #36

So how did they go about making these fixes? Is this another thing where I have to download something from my OEM? The biggest problem I have by far with any of this is that it's not trivial to update all firmware involved. Everything else is forgivable, people make mistakes.

How can you classify a deliberate architectural decision to trade away security for all for the convenience of some as a mistake? That the ME would eventually be exploited was completely foreseeable, and was surely foreseen and discussed within Intel. This isn't like some subtle software bug that went undetected. The consequences were known and Intel deliberately chose them.

> a deliberate architectural decision

This is the "not trivial to update" part. The "mistake" part is all the vulns that come out.

Re: Intel patches new ME vulnerabilities

#298

Post by norcalli »

ksec wrote: post #55

>Perhaps the only consolation is that for CVE-2018-3628, Intel says that exploitation is possible only from the same subnet. That is at least a little more comforting.

But if I managed to compromise a single machine on your subnet, then that means all Intel machines I can touch are also vulnerable, no?

Re: Intel patches new ME vulnerabilities

#299

Post by daxorid »

JumpCrisscross wrote: post #240
emsy wrote: post #186

Earlier quoted context omitted.

Their motivations are irrelevant. Consumers aren't datacenters.

> Consumers aren't datacenters Consumers have also shown zero intention of paying more for secure devices. Until we have a public ME hack with real consequences, I do not expect that to change.

Demonstrably untrue. Consumers pay a premium for access to the Apple SEP and App Store review/analysis process (Jekyll and XCodeGhost notwithstanding, it's been a major security success)

Re: Intel patches new ME vulnerabilities

#300

Post by close04 »

dsfyu404ed wrote: post #292
close04 wrote: post #267

Earlier quoted context omitted.

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…

>Nobody should be using XP. Not even on air-gapped networks, totally cut off, with a special support contract from MS, etc. I think you're severely over-estimating the criticality of stuff that's still running XP. It's mostly used for antiquated industrial hardware that gets used 5x a year, maybe (old CNC mills and whatnot), often times with no network. If it gets crypotwalled via flash-drive then someone will reinst…

More accurately, current stats put XP at around 4-6% of the world's desktops. Only Windows 7, 10, and 8.1 beat it. That's more than Linux and more than any MacOS version (more than almost all all of them put together). That would be ~5 million XP machines, give or take.

So we're talking about 5 million machines with an OS designed in the late '90s (20 years ago) and that stopped receiving any meaningful updates 4 years ago.

Most of them are actually ATMs in developing countries like India and they are definitely not air-gapped [1]. The POSReady XP with the bare modicum of support until April 2019 made companies take it as a green light to keep using XP in embedded systems.

Other systems running XP: many of the NHS systems hit by WannaCry last year, many of the systems in UK Police stations, most electronic voting machines and gas stations in the US, most digital signage in train stations, airports, hospitals, or cinemas, parking garage payment machines, so many POSes, even passport security in some airports!

Does this put the magnitude of the problem in perspective? It's a threat from so many perspectives. Your safety, your data, your money, you name it.

[1] https://www.rbi.org.in/scripts/NotificationUser.aspx?Id=1131...

Post reply on HN