• Welcome to TechPowerUp Forums, Guest! Please check out our forum guidelines for info related to our community.
  • The forums have been upgraded with support for dark mode. By default it will follow the setting on your system/browser. You may override it by scrolling to the end of the page and clicking the gears icon.

Intel Management Engine Patched

Joined
Mar 10, 2015
Messages
3,984 (1.07/day)
System Name Wut?
Processor 3900X
Motherboard ASRock Taichi X570
Cooling Water
Memory 32GB GSkill CL16 3600mhz
Video Card(s) Vega 56
Storage 2 x AData XPG 8200 Pro 1TB
Display(s) 3440 x 1440
Case Thermaltake Tower 900
Power Supply Seasonic Prime Ultra Platinum
Damn, so many flaws...
 
Not a CPU one this time. Management Engine. Reminds me again why all management subsystems are a horrible idea...
 
Not a CPU one this time. Management Engine. Reminds me again why all management subsystems are a horrible idea...

Agree...

Funny... if you peek into those pure china Huanan x79 board bios... they have an option to hard disable ME.

I wonder why :roll:.
 
It's best to simply not install the software

You can disable it in device manager or not install it will work still, just like any low level module residing into the bridge, like HPET for example. Software speaks to it in low ring level directly.
 
Not a CPU one this time. Management Engine. Reminds me again why all management subsystems are a horrible idea...

Corporations love those things, it allows a host of nice features. Sure, they could cut it down on consumer models, though.
 
Corporations love those things, it allows a host of nice features. Sure, they could cut it down on consumer models, though.

It allows a host of nice remote management features that have proven less reliable/secure than ideal, but yes. I'd be really wary of using it longterm.
 
You can disable it in device manager or not install it will work still
Incorrect. If the drivers are not installed and management software is missing, there is no attack vector as the flaw is in the software, thus the reason Intel recommends updating their software.
just like any low level module residing into the bridge, like HPET for example
That's not how it works.
Software speaks to it in low ring level directly.
And if the software is missing, the hardware sits and does nothing.
 
Incorrect. If the drivers are not installed and management software is missing, there is no attack vector as the flaw is in the software, thus the reason Intel recommends updating their software.

The flaw is in the ME firmware, not the driver. They aren't issuing a driver update to correct this.

And if the software is missing, the hardware sits and does nothing.

Not really. That's the whole issue with the management engine and similar systems: They operate as long as they haven't been told not to. To date, that is only possible via Intel ME, and only via undocumented methods.

All the drivers do is give you access to services they provide, they don't stop them from working if you don't load them.
 
I blame U.S. govt. We all can comprehend why CPU makers need to push remote management systems on consumer platform.
 
The flaw is in the ME firmware, not the driver. They aren't issuing a driver update to correct this.



Not really. That's the whole issue with the management engine and similar systems: They operate as long as they haven't been told not to. To date, that is only possible via Intel ME, and only via undocumented methods.

All the drivers do is give you access to services they provide, they don't stop them from working if you don't load them.
Please review;
The vectors of attack require local admin access. If no drivers/software are installed, non-admins can not attack the system through this vulnerability, and remote attacks are not possible.
 
Please review;
The vectors of attack require local admin access. If no drivers/software are installed, non-admins can not attack the system through this vulnerability, and remote attacks are not possible.

How did you come to that conclusion from your link?
 
I remember back in the day it was possible to deblob ME with me_cleaner but on newer systems it's impossible to remove ME firmware.
 
The vectors of attack require local admin access. If no drivers/software are installed, non-admins can not attack the system through this vulnerability, and remote attacks are not possible.

That has nothing to do with where the vulnerability lies (in firmware), or how the base management engine functions, which is what I was talking about. I was speaking generically and not catering to this one vulnerability.

I remember back in the day it was possible to deblob ME with me_cleaner but on newer systems it's impossible to remove ME firmware.

It's not, you can still remove the partitions with other tools, but it's really really hard to truly deblob it without tripping the 30 minute hang timer. You can turn it off with some hackery pretty easily though.

How did you come to that conclusion from your link?

It says so deep in the docs. He's right in regards to this one exclusive vulnerability.

Of course again, it comes down to how one defines "locally authenticated."
 
It says so deep in the docs. He's right in regards to this one exclusive vulnerability.

Of course again, it comes down to how one defines "locally authenticated."

I was more referring to your comments about me functionality and the rest of your entire post. I am rolling on mobile so navigating some things sucks.

It also says right in the docs it is releasing a firmware patch.

I mean I don't see any embedded links to get further into the docs...are they fudging mobile?
 
That has nothing to do with where the vulnerability lies (in firmware), or how the base management engine functions, which is what I was talking about. I was speaking generically and not catering to this one vulnerability.
I was referring to this vulnerability. RTB, we've been over this before. There are no attacks that can render system control through the IME hardware without a software layer component. Such vulnerabilities reside exclusively within Windows as driver sets for other OS platforms either do not exist or are specifically engineered to prevent unauthorized access through the IME hardware. Additionally, such vulnerabilities can only be access by/through Intel network devices hardwired to the chipset. Network chipsets from other vendors are not vulnerable. Network devices not hardwired to the board are also not vulnerable.

All of the vulnerabilities associated with the IME require that each component of the CSME subsystem platform be both present and functional. If any one component is not present(disabled or not installed), not configured property or is restricted by system policies the vulnerabilities can not be exploited.

If you do not install the hardware drivers in Windows, the vulnerabilities are null.
If you disable the hardware in the Windows device manager, the vulnerabilities are null.
If you do not install the Advanced Management software in Windows, the vulnerabilities are null.
If you do not properly configure or provision the AME, the vulnerabilities are null.
If you do not use the provided(built-on) Intel network connection for network/internet access, the vulnerabilities are null.

The reason Intel lists these vulnerabilities has "High Risk" is because a lot business' and companies do use the IME as intended and properly configured. For us end users, the problem isn't as important because most of us don't use/need the IME. Disabling it in the Device manager, not installing the drivers/software effectively guarantees safely for any attack against the IME.
 
Last edited:
There are no attacks that can render system control through the IME hardware without a software layer component.

I think there are some, but they are so old as to be irrelevant.

I as a security researcher, get my head all worked up over the theoretical rather than the here and now. Comes with the territory.

The thing that bugs me about the Intel Management engine is it can pretty much snoop on anything it wants once compromised, driver or no driver. The compromise vector at that point becomes largely irrelevant.
 
Last edited:
MEs should only be LAN/Intranet accessible not WAN/Internet.
 
The thing that bugs me about the Intel Management engine is it can pretty much snoop on anything it wants once compromised, driver or no driver. The compromise vector at that point becomes largely irrelevant.
While that is true, the firmware for the IME resides in the BIOS of the host system and can not be re-written without the knowledge and consent of the system user. Additionally, even if exploited, the IME does not have static ram on die, it has dynamic ram and only a small amount of it. Like system ram, once powered off, the contents are gonesville and the exploit is gone with it. Then even if you manage to exploit the IME and install a package in the firmware, outside Windows the IME can only connect to network adapters it is directly wired to, which will always be an Intel LAN chipset. If that network adapter is not in use by the user, the exploit sits doing nothing.
 
MEs should only be LAN/Intranet accessible not WAN/Internet.

They already are. Thing is that rule doesn't matter when it's repurposed via some malware, as an example.
 
The discussion over IME and its vulnerabilities have been going on for over a decade, it was called something like the NSA spyware chip due to the rumored remote back door. If a patch for it makes big news, its likely there was more patched than was noted, like that back door is working again?. :rolleyes:
 
If the backdoor really is, then communicating with HW with direct commands altering the needed memory registers to make a magic pattern and when bridge MCU fetches the key it will wake up. It ain't no rocket science. Driver is not needed for sure.

Sad part.

Why a regulator has not steped in here? It is an optional component, system works without it. It has to be opt in. Alaska AMI allows to set up a proper disable/enable option for it.
 
It is an optional component, system works without it.
Intel's ME is required for initialization of the CPU cores before any booting can take place.
 
Intel's ME is required for initialization of the CPU cores before any booting can take place.

Could you show some documentation? It is kinda the info pushed to us to believe. Why cutting out(HEXEDIT) that region in certain board bios allows them to boot anyways? ME is one thing CPU microcode is different. Also how CPU init is done. The ME in the PCH part is marked often as a core, while it is not, it is a module, the part handling the boot process is a different module.

For example boot process on certain ASUS boards is handled by their proprietary EPU/ROG engine IC, that interferes with the LPC controller(that's the one waking all system up not ME). It is done because of different HW boot training process, especially when doing OC.
 
Back
Top