Intel vPro - What it can do, what it *can't* do, and what it means for your future hardware choices

General Discussion
122

Least they understand the trust issue even if assume “compelled” somehow.

Intel aside

Why are so many willfully ignorant that Intel = intel (US intelligence)? Wasn’t this clear last millennium in the 1990s -the BBS days? Never understood this. Sure AMD (Advanced Micro Devices spun off manufacturing operations in the form of GlobalFoundries Inc., a multibillion-dollar joint venture with Advanced Technology Investment Co., an investment company formed by the government of Abu Dhabi ) but that does not change the fact that all Intel processors made since 1995[95][96] (besides Intel Itanium and pre-2013 Intel Atom) had been subject to at least two security “flaws”.

Are you serious Tommy aka TommyTran732? WTF are you even attempting to say besides “You need to have a coherent threat model”? Here’s some simple questions @TommyTran732 do you trust Intel? Do you trust AMD? Which do you trust more, if either, why?

Thank you for your sanity @de_dust2 !

Oh how I wish that were so but as you say

So glad Patrick is here

123

Correct me if I am wrong, but I think there is a workaround to use vPro systems safely in the Qubes OS context, specifically to prevent Intel AMT remote access.

Intel states in their documentation here:
https://www.intel.com/content/www/us/en/developer/articles/guide/getting-started-with-active-management-technology.html
that remote management via AMT can only be done through an Intel AMT-supported WiFi device:

Physical Device – Wireless Connection
By default, any wireless Intel vPro platform will have an Intel AMT enabled wireless adapter installed, such as an Intel® Dual Band Wireless-AX 201. Any wireless adapter other than one from Intel will not have wireless Intel AMT capabilities.

If we accept Intel’s claims about vPro capabilities as upfront, we should also accept their claim about the hardware needed for AMT to work, as they are equally explicit.

But let’s say, for argument’s sake, that Intel’s claim is incorrect and AMT could somehow use non-Intel WiFi devices for remote access. For this to happen, the WiFi device would likely need to be internal, as IME can theoretically control internal devices, including an internal WiFi card.

However, what if we completely remove the internal WiFi card from the system, including any embedded WiFi cards on the motherboard, and we avoid using Ethernet entirely? This leaves AMT without a compatible network interface for remote access.

Now, we only connect to the internet using a USB WiFi device. Again correct me if I’m wrong, but IME cannot directly control a USB WiFi device because its drivers are loaded at the OS level. In a monolithic OS, malware or support software might bridge IME to the USB WiFi device, enabling remote access. But in Qubes OS, the USB WiFi device is isolated in the sys-net qube, protected by Xen’s virtualization. For AMT to use the USB WiFi device, it would need to break Xen’s isolation, which seems highly unlikely without a significant vulnerability.

Therefore, I believe that by completely removing the internal WiFi card, avoiding Ethernet, and using only a USB WiFi device in sys-net, we can use vPro-enabled systems in Qubes OS while preventing AMT remote access.

Any thoughts on potential side cases where AMT could still enable remote access in this setup?

124

The AMT that works on top of the ME has a higher privilege than a hypervisor:

Privilege rings for the x86 architecture. The ME is colloquially categorized as ring −3, below System Management Mode (ring −2) and the hypervisor (ring −1), all running at a higher privilege level than the kernel (ring 0).

Intel Management Engine - Wikipedia

1 Like
125

Correct! However, for a remote entity to exploit AMT, it must first reach ME via a compatible network interface. In my scenario, removing all internal WiFi, avoiding Ethernet, and using a USB WiFi device in sys-net, there’s no AMT-compatible interface. Even with ME’s privilege, it can’t access the USB WiFi’s OS-level drivers in sys-net without breaking Xen’s isolation, which is unlikely.

Thus, a remote entity can’t reach ME to trigger AMT.

Note: AMT is configured to use internal communication devices, it cannot go out of its way and use USB WiFi for remote access unless instructed to do so remotely or modified locally. Ignoring local threats, my argument is that this setup ensures a remote entity cannot instruct AMT/ME, as no network path exists.

126

It can. The ME has a higher privilege than hypervisor, so it can access everything.

There is a possibility of something like this:

E.g. AMT could be remotely triggered by some specific calculations done by a malicious javacscript in a browser.

1 Like
127

How is it possible in QubesOS?

128

Commands are still executed by the CPU and the ME has access to all the CPU resources and can see all the commands that are executed.

1 Like
129

Agreed, AMT/ME has higher privilege than Xen, but a remote entity lacks AMT-level access. How could it trigger AMT to use a USB WiFi device in sys-net without such privilege? In Qubes OS scenario (no internal WiFi, no Ethernet, USB WiFi in sys-net), can a remote entity, confined to a VM and not breaking Xen’s virtualization, use CPU instructions to trigger ME to access the USB WiFi device? Any mechanisms or exploits that could enable this?

130

The AMT need to have a hidden integrated functionality that would be aware of different OSes and hypervisors and a be able to gain access to the network in them by scanning the memory and hijacking the network-related processes.
This functionality can be remotely triggered by some hidden circuit that would wait for the CPU to execute some specific sequence of commands e.g. ((1+2)*3/4)&5 with some unique numbers. Additionally the remote attacker could use some of these numbers to send, for example, an IP address for AMT to connect to or some simple commands.
It could even be a two-way communication if this hidden circuit will modify the operation result and instead of 2+2=4 it’ll be 2+2=CPU_ID.

1 Like
131

So, you’re suggesting AMT can has hidden functionality that:

  1. Detects Qubes OS, a user removing all internal communication devices, and using USB WiFi in sys-net.
  2. Autonomously scans memory, hijacks network processes, and uses the USB WiFi without remote instructions.

Correct?

More critically, how could a remote entity trigger this via CPU instructions from a compromised Qubes VM?

If a VM-confined attacker can execute CPU instructions to trigger AMT/ME, it would mean Xen’s isolation is ineffective. This would invalidate Qubes OS’s claim that a compromised VM’s damage is contained, as any remote entity could send CPU-level exploits to harm the entire system.

132

Yes.

When javascript says to calculate 2+2, the CPU will calculate 2+2 for it, as simple as this.

Qubes OS doesn’t claim to protect you from lower-level vulnerabilities like Meltdown or Spectre because it’s impossible to do.

1 Like
133

That implies AMT/IME has free will…

OK, Qubes OS can’t block low-level CPU vulnerabilities. But they require zero-day exploits, and Xen’s developers actively patch such vulnerabilities. Doesn’t Xen, running at a low level, use virtualization to mitigate hardware exploits via IOMMU and VM isolation?

If low-level instructions could trigger AMT/ME or other exploits from with in a VM and XEN/QubesOS can’t stop them, it goes beyond vPro/AMT/IME. vPro or not, no system is safe, as any attacker could bypass Xen’s virtualization and compromise the entire system. That’s a really bold claim! And again if this claim is true it leaves QubesOS and XEN pretty much useless.

134

Not a free will.
If it’ll have a wide functionality integrated inside and could be controlled by executing specific sequences of CPU instructions, then there is no need for a free will.

It’s not running at the lowest level. Hypervisor is running at ring -1 and it can’t control anything running at lower levels System Management Mode (ring −2) or ME (ring -3).

Qubes OS and Xen are useful for protecting against attacks that don’t involve the lower level vulnerabilities like Meltdown or Spectre or some backdoors.

1 Like
135

What this implies goes beyond the vPro issue and the solution I was mentioning to mitigate it.

Intel mentions that only AMT-supported WiFi cards can be used for remote management. If we think they claim this but all WiFi cards can be used, that’s a minor issue. But when you say they’re so sneaky that they consider the possibility all communication hardware gets removed and the user uses USB WiFi, and they embedded code in the CPU that, when signaled, the CPU will understand and activate AMT, then it’s a thousand times more plausible that there’s no difference between vPro and non-vPro processors, and all processors have remote communication functionality.

Since IME has more privilege than anything else, and Xen virtualization and Qubes isolation mean nothing to it, then Qubes OS is not secure on any system in this case.

Maybe then non-vPro systems are more untrustworthy than vPro systems, because people who don’t care about vPro’s privacy implications buy them, while those concerned with vPro’s privacy implications buy non-vPro systems, meaning anyone buying a non-vPro system has something to hide and is more vulnerable to attacks than someone on a vPro system.

This discussion is going nowhere because it’s gone outside the realm of what vPro can and cannot do. If someone has a simpler scenario that stays within the confinement of a vPro system as to why my proposed solution won’t work, I want to know.

136

There could be different cases:

  • Intel has implanted a backdoor with wide functionality that can gain access to the network in different supported systems and could be controlled remotely.
  • Intel has a vulnerability or a backdoor that could be seen as a bug that could enable the AMT either remotely or from the compromised OS.

Your suggestion could help in the second case, but it won’t help in the worst-case scenario.

2 Likes
137

This is A grade paranoia - does not mean it may not be true, but A grade
notwithstanding.

It used not to be a trivial matter to swap out WiFi cards - required
reflashing firmware. Not an issue if you used Heads. (Same for 3rd party
batteries.)

It is absolutely true that AMT provides full remote control of supported
computers. This is a useful feature in some contexts.

It’s also true that Intel have not prioritised security of the system,
and that researchers have found various bugs and holes that are, to say
the least, worrying. But no one, researcher or whistle blower, has
uncovered any such capability.

It’s easy to speculate about what could be done with this sort of
technology. But users should try to evaluate risk - always a hard thing
to do. And that requires some weighting of probability. I dont think
that idle speculation like this serves any purpose at all.

Qubes users are far more likely to have their security broken by
user error than by unidentified speculative features of their hardware.

I never presume to speak for the Qubes team. When I comment in the Forum I speak for myself.
4 Likes
138

If you’re saying not to even mention this kind of an attack then how would someone even consider if they should include it in their threat model or not without even knowing about it?
Yes, the probability is low, but it’s not impossible and it should be up to user to decide whatever to disregard it or not.

2 Likes
139

Totally agree! This discussion was indeed very thought-provoking.

You’re right that discussing such risks helps users build their threat model, even if the probability is low. But as @adrelanos accurately pointed out:

and

This risk isn’t limited to vPro systems, it’s a concern for every system. Since the thread was about what vPro can and cannot do, I wanted to highlight AMT’s limitation to Intel WiFi/Ethernet and how removing these mitigates remote access risks.

Thanks for the insightful discussion, it was super helpful!

Cheers

140

It’s not a free feature, you would need a laptop with vPro enterprise to have access to out of band KVM remote control. You can simply choose not to buy a model with vPro enterprise, it will save you a couple hundred dollars.

vPro systems with AMT don’t always allow you to change the hardware, removing the WiFi card can leave you unable to boot the system.

141

I’ve tested this myself on systems with vPro Enterprise and vPro Essentials, and both type of systems are working fine after removing the internal WiFi card including the wifi cards that are embedded in motherboard.

1 Like