111–120 of 337 posts
Do we really need remote code execution on the bios level? Is this a case of 'we can, but should we?'
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.
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.
Earlier quoted context omitted.
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.
The extent to which this particular strategic business option was discussed during the design phase of the ME is hard to know from the outside. Surely someone within Intel pointed out that the ME was inherently insecure, but as for all the consequences, who knows?
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
Earlier quoted context omitted.
That's to access AMT. AMT is a module running on top of ME and is disabled by default.
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
- 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
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
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 :(
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 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.
Intel only patches its own firmware, but it's normally up to manufacturers to update that firmware for devices. So most PC/laptops users really won't even see these patches.
And I agree with your main point. For one of the more recent Spectre-class flaws, Intel basically said "it's third-party developers' problem to fix."
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…
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…
The proper solution is an optional management chip on the motherboard, not the CPU. PCI bus mastering NICs with wake-on-lan and other management features have existed for decades; it wouldn't be particularly difficult add the rest of the ME features.