181–190 of 337 posts
The CPU list isn't really helping as the answer is just "yes".
What remains is what, that my motherboard and NIC plays along? How can I figure that out? Is buying a non-intel NIC guaranteed to be safe?
Right about bow running pfsense on intel hardware isn't the best feeling in the world.
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.
Things that come with great benefit to risk for abuse:
- Intel ME
- Computrace
- Device Guard
Earlier quoted context omitted.
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 :(
There's always me_cleaner. It's a bit of a pain and requires hardware access to run but better than being exposed to an unpatchable vuln. I encourage every hackspace to set up an ME removal station (I'm building one for EMF Camp this year, and will document it so others can easily replicate)
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
The devices which have the feature enabled are probably business devices and the feature is used to manage them. Business devices are good value targets, I guess.
Edit : I guess those devices will probably receive the fix, since they are managed
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…
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…
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
Every time I am about to upgrade this happens. cpu0: Intel(R) Pentium(R) D CPU 3.00GHz, 2993.01 MHz
Earlier quoted context omitted.
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.
For what it's worth and graphics on Linux are working great with amdgpu. Their efforts to develop and support open source mainline graphics has really finally paid off. Support is usually mainlined before hardware release now. I don't think "just works" integrated graphics are an issue for either company (Intel/AMD) in general on the Linux front. That said the amdgpu driver is still relatively new and major changes a…
Case in point, the ATI Radeon HD 6310 that came on EEE PC models, the video hardware acceleration no longer works as it used to be.
Sure, I can probably hack the older driver into newer Ubuntu releases or track down someone that has already done it, but that is exactly what I don't want to spend my time doing outside work.
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.
Earlier quoted context omitted.
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.