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 
)
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 
)
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 
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 
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 ), 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…
.
