Which of my arguments were non-technical? Which part of it required some magic to be implemented and not feasible technically?
The backdoor in AMT would be the most powerful and hard to detect since it’s integrated in CPU, I guess that’s why all the focus.
And what technical basis/proof are you referring here? You mean that it’s impossible to do technically? Or you want be presented with analysis of silicon floorplan that there is actually a suspicious circuit that could possibly act as a backdoor to call it “technical” discussion?
Of course with hardware it’s endless possibility of some kind of backdoor to be implemented.
The question is where it would be the most powerful and undetected.
And hardware backdoors are not really something unheard of either:
They did look at firmware level, but there is no way to tell whatever or not this bit could be enabled outside of firmware from some separate circuit.
But I’d say that the probability of this is negligible.
Bit toggle could trigger the Intel ME to reinitialize. But I don’t know whatever it’s possible to fully initialize after starting with HAP bit at first.
Yes, that would be non-persistent and one-time only until power off. But that means that it won’t leave any traces either.
Just to be clear, I’m not talking about modifying the ROM.
I’m talking about additional AND gate like this:
| | <--- HAP bit read from ROM
Real HAP value that <---| AND gate |
would be used by Intel ME | | <-- signal from hidden circuit to activate
Intel ME even with HAP bit set
And the output of AND gate could be used for Intel ME reset/reinit on falling edge after initial start up with HAP bit set.
The hidden circuit won’t need to be complicated like second Intel ME and could be some trivial circuit that would wait for specific sequence of commands to be executed in the specific timeframe like a+b → c*d → e/f.
This stuff is just conspiracy la la land, you really need to back it up with something. You can theorize all you want, but you can say that about anything, Intel AMT, AMD PSP, Intel CSME, Intel TXT, TEE, Secure Element, Pluton chip, Titan C, Titan M, everything under the sun…
There is a difference between saying some kind of design is questionable and may be exploited by an attacker, and literally just theorize that the vendor is malicious and will backdoor everything. If someone uses an Intel CPU, Intel is in the trusted computing base, and there is no way around it. Making ridiculous hypotheticals about 1 component while ignoring the rest is just not helping anyone.
I disagree with your approach of blindly trusting vendor and not even trying to think about any possible threat from the vendor and of a possible way to prevent it.
And I’m not talking about just Intel AMT, but Intel ME/AMD PSP/ARM TrustZone and any other hardware in general.
I’m not saying don’t use hardware with Intel AMT at all and use some old hardware without even Intel ME instead.
I’m saying that you need to consider all possible threats and try to find a way to prevent them.
And I’m not saying that all users must implement all these possible protections from these threats.
But these protections should be considered by those that could be assessed as valuable targets.
I’ll give you an example:
Lets assume that Intel AMT could initiate outgoing connection when user executes some javascript code in browser.
Lets assume that Intel AMT can use Ethernet or Wireless controller on the motherboard bypassing OS to connect to the network using network configuration used by OS.
Lets assume that Intel AMT don’t scan the OS RAM to find and use the existing network connection in OS level to use instead of using network controllers directly.
How is it possible to prevent this threat?
You can place a separate hardware firewall with VPN server between your PC and internet. Connect to the VPN server running on this firewall in your OS and connect to internet through this VPN connection. Configure firewall to filter all the traffic except for the one going through VPN.
Done, possible threat prevented.
The same could be done for other hardware components.
Possible leakage of the disk encryption key using any possible channel including vendor backdoor?
Decrypt the disk on a separate hardware and use this disk over network. Done.
So the main problem is assessing the possible threat, it’s probability, the cost of threat prevention measures and the possible damage of the threat.
Many assumptions here, just as before you talked about
*possibilities".
I’m struggling to understand how you think you can trust this hardware
firewall and VPN server, or how the “separate hardware” is not going to
be subject to exactly the same fears as your base hardware.
I dont find these discussions particularly fruitful, but I absolutely
agree that users should assess possible threats. (I dont agree that
this is limited to “valuable targets” for reasons I’ve given elsewhere.)
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
Well, of course we have to deal with assumptions and probability in cases where it’s (almost) impossible to reliable verify your suspicions.
If I can’t verify and make sure that the hardware is not malicious then I can’t blindly put my trust in it.
And if I can’t put my full trust in it then I should search for a possible threats from it and a possible protection from these threats.
I think it’s a valid scientific approach where if something is not proved to be impossible then it should be considered as possible.
That’s a question of probability.
If probability of compromise due to having a backdoor in Intel AMT on the PC without additional hardware firewall is A, then probability of compromise due to having a backdoor in Intel AMT on the PC with additional hardware firewall is A*B where B is probability of having 0-day somewhere in hardware firewall stored in Intel AMT firmware (0-day in VPN software / hardware vulnerability/backdoor in another architecture if firewall is on e.g. ARM machine / 0-day in some other software).
It’s impossible to be 100% certain that there won’t be any compromise, there will always be some degree of probability. All you can do is decrease this probability to the lowest value.
Or if you meant that it’s possible to attack firewall from outside knowing that the target PC is behind it and then enabling the Intel AMT traffic on this firewall after its compromise then it’s the same question of probability where you need to have a way to attack firewall in addition to having a way to compromise PC using Intel AMT.
I am not sure what is there to be confused about. It’s just the security advisory for Intel products.
Security vulnerabilities are gonna happen, and someone will put out an advisory and steps to mitigate those vulnerabilities. It’s just how it works in the industry.
Why are you just saying random incoherent stuff? Please actually read both what is being posted here and the link you yourself sent.
AMT is not magically vulnerability free. No one is saying “AMT is from Intel therefore it must be impossible to attack it.”
The general recommendation is that AMT is unnecessary on most systems, and the user should disable it for attack surface reduction if they do not need it.
Whether AMT is on or not depends on the firmware setting. The user has the option to disable it. The vulnerability you posted are only exploitable if AMT is running. The user can verify whether it is on or not by checking port 16992 and their own firmware setting. An attacker cannot magically attack the authentication mechanism on a web server if the web server isn’t even running in the first place.
I disagree with your approach of blindly trusting vendor and not even trying to think about any possible threat from the vendor and of a possible way to prevent it.
And I’m not talking about just Intel AMT, but Intel ME/AMD PSP/ARM TrustZone and any other hardware in general.
You see, this is the problem.
There is a big, big difference between making assumption that certain feature is vulnerable and whether the hardware vendor is actively malicious.
If you think that AMT is vulnerable/exploitable, and that is a perfect assumption to make, and you absolutely should disable AMT. This is the general security practice when it comes to AMT.
If you think that peripheral vendors like Realtek with their Wifi/Bluetooth cards or Qualcomm with their WWAN modules are malicious, you can isolate their stuff via IOMMU and make sure that so cannot DMA the actual system memory. That is perfectly reasonable. This is also general security practice when it comes to stuff that are connected over PCIe.
If you think that Intel is so malicious that they will actively introduce a hidden feature in AMT where it will activate when a certain Javascript and do stuff behind your back, then your only choice is to not use Intel CPUs. That is because, if Intel is actively malicious like this, they can backdoor any number of things like the CPU/Microcode to introduce another Spectre and screw you over. The CPU and its vendor are forever part of the trusted computing base and there is absolutely nothing you can do to distrust them. This is where hypothesising that a certain CPU vendor is so malicious that they will go out of their way to backdoor a specific component but will not compromise any number of other stuff become extremely unreasonable.
Well, that’s a bit simplistic (in my eyes, that is). Anything made by humans tends to be flawed in some way. So perfection is not a basis for trust here. Let’s read again:
It seems to me that you are taking things to the extreme of logical denial, while ignoring some basic historical facts:
On May 1, 2017 Intel disclosed the AMT vulnerability (INTEL-SA-00075), **but details of that vulnerability were not made public**.
That’s why “the CPU is in the tcb, deal with it” is a bit… well… just part of the game. While you seem quite happy about it, I’m not. While you think it’s enough to change the bios setting, I think it’s not … let’s agree to disagree.
I don’t know what “basic historical facts” you are trying to talk about. Say I have a product that’s a remote management system that happens to be vulnerable, would you rather I…
Give an advisory saying “Oh yeah it is vulnerable. Please update ASAP”, then wait awhile before I give the details.
Give an advisory saying “Oh yeah it is vulnerable, here is how you can go about exploiting it. Let’s goooo!” before giving people a chance to update?
For context:
The advisory was out on May 01, 2017.
The blog post you linked was out on May 05, 2017.
If I am an Intel customer, I would rather Intel not tell the world how to go about exploiting AMT (especially if I am using it for my sysadmin tasks) until have the chance to patch my fleet.
I am not sure what you are even trying to do by posting about TXT can be bypassed by attacking SMM. Stuff like this is why modern laptops have SMM mitigations to make it harder to launch attacks against it. And even if TXT is defeated, you are only defeating DRTM, it’s not some magical system backdoor.
The way I see it, you are taking things to the extreme of logical denial, insisting on some shady business at Intel by posting random stuff that you yourself didn’t even read. You need to stop insinuating stuff without real, hard proof.
If you read the linked article carefully, I’m sure you noticed that Intel — again — defined interests in a way that was … let’s say “not necessarily customer focused”. The whole idea of “trust” defined by vendors is wrong IMO. The author’s judgement was analogous. (See the footnotes, too, please.)
And by the way, just because something suits you (or me) doesn’t mean it’s right. So for me, your whole analysis is a bit apodictic. (And that’s why I’m out. I made my point. I didn’t expect you to agree.)