So, in the internet slang, Intel has been pwned so hard. On a different approach, this is very bad news. Financial analyst will exploit this news to disrupt Intel's net worth. On enterprise level, this is very inconvenient. So many devices are running with Intel chips. This opens a new era on hardware hacking as never before. Some nefarious individuals will make sure to develop new tools and pivot from this new breakthrough as they see fit. Let's see Intel response, maybe they will come up with something. This is a red letter day.

anticupidon:

Financial analyst will exploit this news to disrupt Intel's net worth. On enterprise level, this is very inconvenient.

No. In the past we saw it means absolute nothing. Nobody cares, no matter how many security holes Intel CPUs have. While I say nobody, of course the IT staff does care, but their complaints will fall on deaf ears.

This vulnerability needs physical access to servers/computers in order to be exploited - can't be done remote. If you are a system administrator and allow unsupervised physical access to your servers/computers you should find yourself another job. So let's not overreact, it is a vulnerability but not as serious as remote code execution or other kind of vulnerabilities that can be exploited remote.

barbacot:

This vulnerability needs physical access to servers/computers in order to be exploited - can't be done remote. If you are a system administrator and allow unsupervised physical access to your servers/computers you should find yourself another job. So let's not overreact, it is a vulnerability but not as serious as remote code execution or other kind of vulnerabilities that can be exploited remote.

Um....What? This, unless i'm reading this wrong, has nothing to do with accessing physical devices, it has to do with the fact that people theoretically can access the CPU security patches and microcode, which'll allow them to see how the security holes are patched, and find work arounds. This isn't to do with a "single" device, but theoretically, all devices. The only part that would require physical access is this: "The key may also allow parties other than Intel—say a malicious hacker or a hobbyist—to update chips with their own microcode, although that customized version wouldn’t survive a reboot." Which is moot point.

this is generally good news imo, it means that FINALLY microcode can be issued by others than intel, which means that old chips now have the potential to have bugs patched that intel is unwilling to do. it also probably means that the ME can be completely disabled now.

Aura89:

Um....What? This, unless i'm reading this wrong, has nothing to do with accessing physical devices, it has to do with the fact that people theoretically can access the CPU security patches and microcode, which'll allow them to see how the security holes are patched, and find work arounds. This isn't to do with a "single" device, but theoretically, all devices. The only part that would require physical access is this: "The key may also allow parties other than Intel—say a malicious hacker or a hobbyist—to update chips with their own microcode, although that customized version wouldn’t survive a reboot." Which is moot point.

https://software.intel.com/security-software-guidance/secure-coding/loading-microcode-os

so, you can hack yourself, again. Unless you hack the code (ME) waiting to be deployed world-wide. If you manage that, well, you will be soon employed in some government.

This is double edged sword. On one part, freedom partisans will clear out Intel's ME and liberate the platform from obscure code and implementing more code, free code. Open source code. Coreboot and Libreboot projects will flourish. On the other part, this open the door to malicious people, willing to inject nefarious code into hardware, to control at the highest level a machine. How to do it and complications to physical acces to a machine is rather trivial, because social engineering is booming today. Search for OSINT tools and you'll wish to never open an account on social media platforms. Imagine the scenario: one employee goes with the faulty computer to a repair shop , the code is implemented and running...and the computer goes back to its owner. Then, the machine connects to some bussines platform. With the code running and without being detected.

" Then, the machine connects to some bussines platform. With the code running and without being detected. " Nope. Like all Intel exploits before, for every machine you will need a lot of know-how and it's CPU by CPU, no mass attacking machines, unless you somehow manage to push ME update via M$ or Intel network meaning MB BIOS/UEFI etc.

user1:

this is generally good news imo, it means that FINALLY microcode can be issued by others than intel, which means that old chips now have the potential to have bugs patched that intel is unwilling to do. it also probably means that the ME can be completely disabled now.

That's an interesting take on a silver lining, but, you have a good point. Makes me wonder if it's possible to use the microcode to unlock the CPUs too. So for example, turn a non-K model into a K model. As far as I'm concerned, there is no physical difference between K models, but maybe I'm wrong.

anticupidon:

This is double edged sword. On one part, freedom partisans will clear out Intel's ME and liberate the platform from obscure code and implementing more code, free code. Open source code. Coreboot and Libreboot projects will flourish. On the other part, this open the door to malicious people, willing to inject nefarious code into hardware, to control at the highest level a machine.

So far, open-sourced code hasn't been much of a security threat, because as long as people are all updating frequently enough, any discovered vulnerabilities get patched rather quickly. More eyes on a problem yields more awareness and potential solutions. Although I don't frown upon "security through obscurity" as much as most FOSS diehards, it has worked for Intel for a very long time. It took like... 15 years for it backfire. I remember a few years ago, the "eject" program in Linux had a security vulnerability. The only way that bug would've been noticed was through its source code. You can look at this situation as "by making it open-source, it is now ensured to be secure" but at the same time, if it were closed source, there's a very good chance nobody would have ever found it, because who seriously looks at the opportunity of ejecting a DVD as a moment to start hacking, especially these days? Meanwhile, there's also the idea that if someone malicious discovered that vulnerability (which they could relatively easily do, since no reverse-engineering is involved), they would've kept quiet about it. I would argue the best way to keep things secure is for multiple people with a security background to inspect the code before it is deployed. That way, even if one of them is basically a spy, the chances of them getting away with their discovery is reduced.

Imagine the scenario: one employee goes with the faulty computer to a repair shop , the code is implemented and running...and the computer goes back to its owner. Then, the machine connects to some bussines platform. With the code running and without being detected.

Yes, that is a pretty dire situation. But, I'm sure antimalware programs will soon enough do hash checks on microcode.

Disturbing news, none the less. I wish Intel to find a solution, a solid and easy to deploy. Problem is that a huge lot of machines will be left unpatched, so there is where trouble will start.

If an "independent" security firm could, u HAVE TO/MUST assume bigger players have already done it before (every 1st world country) by means of cracking or simply "asking" Intel for the keys.

schmidtbag:

That's an interesting take on a silver lining, but, you have a good point. Makes me wonder if it's possible to use the microcode to unlock the CPUs too. So for example, turn a non-K model into a K model. As far as I'm concerned, there is no physical difference between K models, but maybe I'm wrong. So far, open-sourced code hasn't been much of a security threat, because as long as people are all updating frequently enough, any discovered vulnerabilities get patched rather quickly. More eyes on a problem yields more awareness and potential solutions. Although I don't frown upon "security through obscurity" as much as most FOSS diehards, it has worked for Intel for a very long time. It took like... 15 years for it backfire. I remember a few years ago, the "eject" program in Linux had a security vulnerability. The only way that bug would've been noticed was through its source code. You can look at this situation as "by making it open-source, it is now ensured to be secure" but at the same time, if it were closed source, there's a very good chance nobody would have ever found it, because who seriously looks at the opportunity of ejecting a DVD as a moment to start hacking, especially these days? Meanwhile, there's also the idea that if someone malicious discovered that vulnerability (which they could relatively easily do, since no reverse-engineering is involved), they would've kept quiet about it. I would argue the best way to keep things secure is for multiple people with a security background to inspect the code before it is deployed. That way, even if one of them is basically a spy, the chances of them getting away with their discovery is reduced. Yes, that is a pretty dire situation. But, I'm sure antimalware programs will soon enough do hash checks on microcode.

Best option ...dont buy Intel until they get themselves sorted!

It's been a shitshow with Intel almost constantly since the first Spectre/Meltdown new dropped. Before that it was still all good, Coffee Lake was fresh and had exciting OC capabilities, you could play with the chip by delidding it, competing in everything but the best multicore optimized apps with the first gen Ryzens, at an often lower price. Things looked fine, not great, but fine. Fast forward 3 years, and ohhhh boyyyy Intel is in deep trouble. Only their deep pockets can save them, which I hope happens, just like it happened with Core 2 Duo. What matters is that WE, THE CONSUMERS, win. Let the corporate scum fight it out.

gx-x:

" Then, the machine connects to some bussines platform. With the code running and without being detected. " Nope. Like all Intel exploits before, for every machine you will need a lot of know-how and it's CPU by CPU, no mass attacking machines, unless you somehow manage to push ME update via M$ or Intel network meaning MB BIOS/UEFI etc.

We can safely assume, but we don't really know facts, because of the whole obscurity surrounding the IME. But you have a point. I was just extrapolating wildy. However, some hackers are even wilder at doing nefarious things and nobody will stop them.

toyo:

It's been a shitshow with Intel almost constantly since the first Spectre/Meltdown new dropped. Before that it was still all good, Coffee Lake was fresh and had exciting OC capabilities, you could play with the chip by delidding it, competing in everything but the best multicore optimized apps with the first gen Ryzens, at an often lower price. Things looked fine, not great, but fine. Fast forward 3 years, and ohhhh boyyyy Intel is in deep trouble. Only their deep pockets can save them, which I hope happens, just like it happened with Core 2 Duo. What matters is that WE, THE CONSUMERS, win. Let the corporate scum fight it out.

Let's not running to AMD with open arms. Quite the contrary. I am not crazy. I have an AMD computer... However, in some boards IME was succesfully nuked or half nuked. In some boards it was replaced with Libre or Coreboot binaries. But how many boards can disable the latest iteration of AMD's Platform Security Processor?