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

Continuing the discussion from Qubes ready to install for Journalist-Human Rights workers:

@qqubes, I’ve forked this conversation topic, to keep it separate. There is way too much to talk about, and it would get a lot of people confused (and potentially frustrated) in the other thread.

No, not at all. Intel seems to be very upfront about which of their hardware contains vPro functionality.

I’m not saying that either. vPro appears to require some sort of extra hardware. So it doesn’t appear to be able to be “backported” to older hardware. Similar to the Intel ME. (If it was, don’t you think they would have done that?)


What I am saying is this:

  • vPro allows computers to be remotely controlled via the Wifi NIC

  • vPro allows remote KVM functionality

    • Someone can remotely view your screen(s) at any time, including during the BIOS boot
    • Someone can remotely see what keys are pressed
    • Someone can remotely type keys
    • Someone can remotely move the mouse cursor
    • Someone can remotely turn the machine off
    • Someone can remotely turn the machine ON (an OS cannot usually turn itself on)
  • vPro allows remote interaction with other hardware components

    • Someone can remotely update the BIOS (I’m assuming)
    • Someone can remotely update firmware of attached devices (I’m assuming)
    • Someone can remotely add/remove/alter files on attached storage (I’m assuming)
    • Someone can remotely execute code on the CPU (I’m assuming)
  • vPro allows remote control of a machine while it is “out-of–band”

    • Someone can remotely reset the computer if the OS is frozen
    • Someone can remotely touch the hard drive while it’s infected with malware
    • Someone can remotely bar the OS from accessing the network hardware, while still allowing vPro to “administer the machine”
    • Someone can remotely interact with the machine while it’s turned off
  • All of this takes place in the code of the Intel hardware that the OS sits on

    • The OS has no way of knowing that this exists, let alone be able to interact with it

Why would you want to do this?

Imagine you’re managing work computers for employees of a big company. You have 30,000 computers across 20 countries, and a lot of them are working from home.

Imagine how many computers you’d have infected with malware every day. Imagine how many employees you’d get complaining that something’s “not working”.

(If you’ve ever worked in corporate IT, you’ll know exactly what I’m talking about :expressionless:)

Wouldn’t it be nice to be able to interact with the machines as if you were in front of them? You could perform functions that most remote access platforms can’t do, like power cycling, plugging in and unplugging peripherals, resetting a frozen OS, and even being able to “airgap” a malware-pwned OS, while still being able to fix the machine without physically being in front of it.

How does Intel do this?
(DISCLAIMER: This is only speculative, and I am happy to be corrected on this)

Well, the same way that most things on the internet work.

A FaceTime call between two iPhones doesn’t only involve those two iPhones.
(You’d be surprised to know how many people actually think this is how it works :face_exhaling:)
Apple hosts a FaceTime server (multiple, actually), and both iPhones connect to it and “ask for instructions”. As a result, all data is relayed by the server to both iPhones.

This is how the majority of apps work.

I’d imagine that Intel would have a server somewhere that Intel host, that all Intel hardware connects to and “ask for instructions”…

Does this have the potential to be misused or compromised?

Why yes, yes it does, very much so. The way I imagine it’s supposed to work is Intel will accept requests from their clients to send directives to certain registered Intel hardware (clients would enrol their hardware into it). This would allow them to deny this functionality to anyone who didn’t pay their bills, and would allow Intel to see how it’s being used, and they could make improvements to it, add extra functions that their clients might find useful, etc.

Wait…if the hardware isn’t enrolled, does it mean it’s unaffected and safe, and I can have vPro in my computer and not worry?*

I honestly don’t know, but do you really think Intel doesn’t keep track of their hardware? They know every serial number of every product they’ve ever made (all successful big companies do this). I would imagine that they’d still have a way to issue hardware with directives…

Despite Google saying that Android was “Open Source” and had no backdoors, Huawei devices were suddenly unable to upgrade to the latest version of Android as soon as the Huawei sanctions came into effect…

Just something to think about…

So what could potentially happen to my Intel hardware with vPro?

1) State Actors / Influential Organisations

Intel hardware will likely accept any directives that come from Intel (and can be verified as coming from Intel), and those directives could be anything that vPro can do to the machine.

Influential companies or governments, for example, could potentially force Intel to send certain devices certain directives.

Send your IP address to someone, dump your RAM, extract your encryption keys, remotely control your machine, watch your screen, delete your files, install rootkits in your OS, turn your machine on while you sleep and do things to it, view your webcam, listen to your microphone, and probably so much more…

2) Blackhats and Criminal Organisations

Because of the way computer networks work, Intel hardware will also accept any directives that look like they’re coming from Intel. This means that anyone who can convince Intel hardware that they actually are Intel, will be able to tell that hardware what to do, and it will do it without question. This would usually require some sort of key/signature verification.

But they’d be able to do all those things I listed above as well, until Intel changed their keys and distributed them.

I just realised that my hardware has vPro. What can I do to counter this?

It appears that vPro uses regular wifi protocols and the same internet infrastructure that the OS uses. It’s stealth lies in the fact that the machine it’s running on won’t be able to detect it. But the infrastructure it’s connected to definitely will be able to see.

Is your computer off, but your router says it just downloaded 45GB? That’s a pretty good indication that vPro is doing something.

So, I could potentially block this using my firewall?

Unclear. Possibly, but I wouldn’t get your hopes up…

Can vPro receive directives if it’s not connected to a Wifi network?

I don’t know, but I would imagine it wouldn’t work without a way to talk to a control server…

Bear in mind that if someone really wanted to get to you, all they’d need to do was broadcast a wifi signal near your machine, with a signal that all vPro hardware would automatically respond to. That’s very possible…

Look, my guess is that Intel would have something up their sleeve for this scenario, but we just don’t know…

Will Qubes OS’ awesome sys-net stop this?

Sadly no. sys-net won’t even be able to detect it, and unless Intel gets sloppy with their vPro code and leak it to the OS, it probably never will :frowning:

Do I need to keep my laptop inside a Faraday cage bad when I’m not using it?

If you can’t remove your wifi chip/card/dongle, and you don’t want vPro to do stuff when you’re not using your machine, yeah, that’s one way.

Another way that should work is to remove all power sources from your laptop, especially to the vPro hardware…

But hey, don’t hold me to this. I don’t want to see anyone unnecessarily pwned…

How likely is it that any of this will happen to me?

It depends on what you’re doing, whom you’re doing it to, and how influential they are :wink:

Well, that’s an assessment you’ll have to make on your own.

If you aren’t planning a terrorist attack (please don’t, there are other ways to get your message across :frowning: ), aren’t trying to expose a prominent political figure or dictator from within their own territory, or aren’t running a darknet marketplace; then there’s a chance that this will never happen to you.

I’m just saying that the capability is there in the hardware.


@qqubes, does this make more sense now?


GLOSSARY FOR CONTEXT

Software Stack

Software isn’t one big program (the very first computers in the 1950s were like this), they are lots of little programs that “slot into each other”.

For example, a conventional “boot stack” for an X86 UEFI computer running Linux would be:
Electricity enters the motherboard → Binary on BIOS chip → Bootloader (GRUB, LiLO, etc) → Linux Kernel → OS components (systemd, OpenRC, SysVinit, etc.)

Each one of those programs starts up, does what it needs to do, and then “calls” for the next program. So, it can be thought that they’re “stacked” on top of each other.

System/Function Calls

Imagine if developers had to know which individual zeros and ones to turn on and off inside every single CPU… There would be way too many binaries, and you wouldn’t be able to take software from one CPU class to another (eg Intel i5 to Intel i7) and run it.

The Linux kernel contains readouts and capabilities for quite a lot of chips. It’s awesome, it’s what makes it so great. The program code is basically compiled into “system calls”. Basically, the function is determined by the compiler, and is then written into

A very basic example would be a program to add 2 numbers/values. Different CPUs will perform these calculations in completely different ways, so to make the program work on multiple CPUs, the program will then “call” the Linux kernel and say something like this:

add( $a + $b)

The Linux kernel then takes that function, translates it into a way that the chip will understand, and then translate the result back into a way that the program will understand.

Another good example is reading a file from a hard drive. Different hard drives store files in completely different ways, but all the program needs to do is “call” the Linux kernel with:

readFile()

and the Linux kernel does the rest.

(I think this is one of the best innovations in computing history).

The Linux kernel can control some hardware directly (usually low-power embedded chips, etc), but there are some CPUs that it doesn’t know what’s on the inside of. X86 CPUs and nVIDIA GPUs are the perfect example.

The Linux kernel can’t interact directly with the Intel CPU. It basically asks it to do something, and waits for the result from the Intel CPU. The Linux kernel has to “call” the MINIX operating system running inside the Intel CPU with one the functions that Intel has designed for it. These are called “Instruction Sets”.

CPU Microcode

This is basically the MINIX OS that runs on Intel CPUs underneath the Linux kernel, and contains, among other things, the Intel Management Engine.

This microcode does important things, such as making sure the chip runs the way it’s supposed to, it doesn’t overheat, it maintains a constant clock speed across the entire motherboard, etc. (You get the idea…)

For all intents and purposes, Intel have never publicly revealed any meaningful information about this microcode running on their chips. One of the main reasons is to protect their intellectual property, which let’s be fair, is a valid reason. (This is also how nVIDIA have kept DLSS a secret in their RTX GPUs)

But the fact that they won’t fully disclose what’s in this microcode does raise concerns about what exactly this microcode is capable of, and that has some people a little concerned and skeptical…

5 Likes

If you are worried about the AMT feature in vPro, you can disable it in the bios, there is an option to permanently remove AMT.

1 Like

Since this is a continuation of the above topic, in that context the best solution is to simply avoid using any computer with Intel vPro (since they are upfront about what hardware has this capability).

Am I missing the point? Of course vPro has legitimate uses as you described, but if someone like myself or a HR worker wants to maximize their privacy (or minimize their probability of being compromised) then simply avoid vPro. Yes?

1 Like

Or are you suggesting that they (Intel) might try putting it in all their systems in the future?

@qqubes Ok, try this then:

How would you feel about me offering you the ability to control your car from anywhere in the world using your phone?

Think of how much easier your life would be…

You could drive it to the mechanic, pick up the kids from school, send it to go pick people it, all without you being in it; which means you’d have more free time.

You could make it automatically find its own parking space, making your life easier.

You could drive your car, even when the engine is off. That’s incredible. Think of how much money you’d save on fuel (ok, if you drive electric, think of how much time you’d save not charging the car!).

Sounds pretty cool, right? And it’s all for the low low price of 1 EUR per month…

The only catch is, any time you want to control your car like this, you have to go through me

That’s right, I’m actually the one who’s telling your car what to do.

Oh, but I’d never ever ever do anything that wouldn’t be in your best interests… I promise… :smiling_imp:

Would I deliberately drive your car off a cliff with you inside it if you didn’t pay your monthly fee? Oh never… :smiling_imp:

Would I run a taxi service with your car while you weren’t using it? Oh never… :smiling_imp:

Would I drive it super fast so that you get lot of traffic fines? Oh never… :smiling_imp:

Would I try to make money from the fact that I know everywhere your car goes? Oh never… :smiling_imp:

Would I allow someone else to control your car instead of me? Oh never… :smiling_imp:

Would I put cameras on your car, claiming they’re for “safety”, but really I just want to see into your house? Oh never… :smiling_imp:

Oh, and by the way, I sleep with my front door wide open, and I hang the car controlling device just inside the doorway, but don’t worry, I’m sure no one would ever steal it from me. I promise you’re in safe hands… :upside_down_face:

(this should make you feel uncomfortable at worst, and infuriated at best)

Now does it make sense? :slight_smile:

For now, yes. At least until some aspects of it become a bit more transparent, and the end user gets more control over the entire process.

Unless you really see the trade-off as being in your favour, but I seriously doubt you do after the analogy above…

So… does this practically mean we’re left with these CPU’s only?

One additional note:

For each consumer-facing vPro-capable CPU that I’ve seen, there is a sibling CPU with a slightly different model number, identical in every other spec, other than the vPro-related features.

This leads me to believe they’re from the same chip wafer, with one with the vPro fuse laser-blown, the other without.

A vPro-certified laptop has intel-specified networking hardware and firmware blobs so that the remote capability can be supported.

The non-vPro-certified version of the same laptop, a few bucks cheaper, with a CPU differing only in the last couple of digits of the model, may also have the exact same networking hardware and firmware.

So.

The non-vPro-certified laptop with the non-vPro CPU doesn’t show the vPro related features in the BIOS or boot messages. However…is the remote-control capability completely disabled in the non-vPro version of the hardware? Is it really just equivalent to disabling the vPro features in the other laptop’s BIOS or is it completely gone?

Only Intel can say.

B

1 Like

Not necessarily :slight_smile:

I mean, I could be wrong about all of this. Maybe they’ve actually done this in a way that actually gives Intel much less control over the entire process than I’m guessing.

But it wouldn’t make business sense to do this :face_with_diagonal_mouth:

This is the part that concerns me…

If it’s potentially going to be baked into all Intel wifi NICs from now on, I might delay my upgrading, or carry around a faraday bag to keep my laptop in so that no wifi signals can reach my laptop while it’s powered off…


You never know, maybe someone will reverse-engineer all network traffic, and figure out a way to block vPro traffic at a network level. That would slow down your router, but it would block anything coming from your internet connection (at least, until they realise you’re doing this, and change their methodology :wink: ).

Wouldn’t stop someone in a black van outside your house with a long-range wifi antenna spamming your house with a “vPro devices, ASSEMBLE!” signal and waking them up, though :stuck_out_tongue:

And when I say “someone”, I’m of course referring to either a government cooperating with Intel (or forcing Intel to cooperate, they both work :upside_down_face:), or some criminal who stole it from Intel…

I believe that permanently disabling AMT removes the module from the ROM. If I remember correctly, it triggers a sequence with multiple reboots, which I assume is the module being erased from the ROM.

The remote-control capability isn’t very covert, AMT creates an extra network interface with its own IP address. And connecting to the device adds a blinking red border on the screen with an icon informing the user that AMT is being used.

1 Like

Another thing is that AMT is always running even when the system is turned off, I don’t think this is done purely in firmware. You need a vPro enabled CPU, but you also need a chipset that supports AMT.

1 Like

I’m sorry, but with all due respect, until I see a ROM dump, I’m not convinced :slight_smile:

It makes absolutely no sense to allow an end user to alter the binary on a ROM chip, especially to remove functionality. Why on earth would a hardware manufacturer risk potentially bricking their product by making unnecessary writes to their ROM chips?

The official remote control capability isn’t covert. There will be some people on this forum who might actually need to prepare themselves against any potential “special” functions that this might contain (you know who you are :wink: )

I had a feeling this would be how it worked. It would be fairly easy to detect by analysing network traffic.

@renehoj, does the OS know that this extra interface exists, or is it hidden from the OS?

That would certainly be a requirement. A vPro NIC can shout at a CPU all day, but if the CPU doesn’t understand it, it’s not going to do anything.

Unfortunately, modern computers are never truly off unless their battery is disconnected and power cables unplugged (and in some cases, hardware clock battery disconnected).

Not only would this mean that vPro potentially drains your battery faster, but that there would be chips on your board with perpetually executing binaries.

That’s both good and bad, depending on what those chips are doing, and who/what can interact with those chips…


On a side note, it sounds like the hardware is actually multiple NICs in the same module, which is actually kind of cool.

If vPro could be purged from the hardware and unlocked, that would be you’d have a wifi card with two interfaces. If you are wondering why that’s advantageous, search the web for “Blackarch” :wink:

You know it’s doing that because it was programmed to do that, right…? It could just as easily be programmed to not notify the user…

I’m just saying, we haven’t seen any evidence proving definitively that that functionality is not present

Maybe we do need a ROM dump :rofl:


Apologies for being the devil’s advocate, but I still find it hard to believe that an end user can remove anything from a chip in a consumer device (it would literally be one of the only consumer devices in history to be made this way; and I find it nearly impossible to believe that the manufacturer would create a tool that would make their expensive hardware components effectively “dead weight”…


Turns out that there was a massive vulnerability with it in 2018.

This guide seems to list the listening ports. It would make sense that


Interesting thread from a decade ago about it being off in the BIOS, but still making a DHCP request…

https://forums.ivanti.com/s/question/0D71B000005BQjuSAG/detail?language=en_US


For anyone wanting to check their Qubes OS machine for Intel AMT:

You write to the flash every time you update the bios, microcode, or intel management engine, don’t know why you think this would be something different.

I have only seen the AMT menu on ThinkPads, it has 3 options enable, disable, and permanently remove.

Don’t know what the design reasons for the last option were, but I assume they needed it to make sure a bad actor couldn’t use AMT to backdoor the device by having physical access and enabling/configuring AMT.

About the car: it reminds of the show Uploads (Amazon Prime) :slight_smile:

Actually @brendanhoar clarified things with his post. There may be the possibility that a non-vPro CPU in fact still has vPro capabilities.

I hope this isn’t a possible issue for the Pursim laptops which I was hoping to get.

Well, yes and no….

These chips that hold and execute a BIOS or device firmware usually are incredibly simple. They contain a single binary that automatically executes as soon as the chip is powered on. When these chips are written to, it’s not like copying a file to NAND flash (I wish it was that simple sometimes…). Because of this, if you want to change even a tiny part of that binary you have to recompile that binary and flash the entire contents of the chip.

That’s why there’s usually a big “DO NOT TURN OFF YOUR COMPUTER WHILE FLASHING OR YOU COULD BRICK IT” warning when using consumer BIOS update tools…

I’m sure you’ve had a BIOS update fail. If you haven’t, then you’re lucky, and you need to tell me your secret :sweat_smile:.

Flashing BIOS and firmware chips sometimes goes wrong, and each flash does take its toll on the lifespan on the chip. That’s one of the reasons why manufacturers try to limit the number of BIOS updates they release to a couple of times a year, and urgent security updates.

But that’s only part of why I’d be surprised that it would alter the device’s firmware and remove a feature permanently. The other part is the logistics of actually doing it that way.

If that’s what it was actually doing, it would need a binary to flash to it. Where would it get it from? The CPU? Wouldn’t that mean that a full backup of a binary without vPro functionality was stored somewhere that the CPU/NIC/BIOS had access to?

What would happen if that hardware was sold to someone else, and that someone actually wanted to use vPro? How would they get it back into the device firmware?

And if you could just “reflash” the device firmware, what would happen to the serial number most likely stored within that binary?

Intel would have an insane number of their vPro devices sent back to them because the customer bricked them….

I’m just saying, it would be so much easier to keep the code for vPro on the chips in the binary, but have it compiled with an option to not execute it. It would also avoid unnecessary writes to the chips, prolonging their lifespan.

This is why I would be surprised if that’s what was actually happening…. :slightly_smiling_face:

And microcode updates aren’t actually stored on the CPU, at least not with Linux. They’re loaded onto the CPU at boot time, along with the Linux kernel, and they are gone as soon as power is lost to the CPU, and need to be loaded on next boot.

Maybe Intel and AMD have some kind of arrangement with Microsoft, and they allow flashing of the internals of the CPU while running Windows. That’s possible. It wouldn’t be the first time (we need more BIOS updating tools released by vendors for Linux and BSD. I mean, they probably used Linux/BSD to build the damn BIOS anyway!)

——

Basically being stuck inside a “docker container” behind a paywall on someone else’s computer, and calling it “the afterlife”.

That would easily be Richard Stallman’s definition of “hell” :joy:

A good story, though…

And a very accurate depiction of what “technology” in society has become….

1 Like

In HP Elitebook BIOS, there is only the option to unconfigure AMT, not remove it.

This is the menu from a ThinkPad, and the permanently disabled does something that requires multiple reboots, at least that is how I remember it.

Anti-theft and CompuTrace have similar options to permanently disable, and similarly to AMT can also be used to backdoor the device.

from this point, you must only belive that this really permanently disables somenting…

From what I’ve read, Disabling AMT through BIOS simply passes a request to the on-CPU ME coprocessor to disable the functions.

That state flag is then stored on-CPU in a small non-volatile (flash/sram?) area for settings and other power-cycle maintained values/state.

There is no published external command or other signal to tell the ME to enable the functions again and Intel claims they have not implemented such a command.

B

What I have learned is to read every letter of the statements, look to each comma and period. Reading that Intel’s statement, the first I’d ask them after this would be: is such a command implementable? Who else could implement it. And so on and so on…

1 Like

I’m sure if one could modify the firmware of the ME one could do it. That module is signed and/or encrypted by Intel and Intel could do so with a future firmware update.

B