Hacker News Reader

Comment by userbinator | Hacker News Reader

Intel underplayed the exploit and told ZDNet that the VISA issue requires physical access to the machines and the Intel-SA-00086 vulnerabilities have already been mitigated.

Am I the only one here who thinks "threat model" and isn't all too worried? Physical access = full control, I've long held that belief and am not happy that this freedom is continually being eroded in the name of ever-increasing ridiculous "security" (a lot of it against the user, for things like DRM, as mentioned in one of the other comments here.)

Debugging/"test mode" features are basically present in all modern CPUs. I would not bet that Intel is the only one.

Edit: such features have been present in CPUs dating back to the late 70s, so perhaps "modern" isn't needed: see http://forum.6502.org/viewtopic.php?f=8&t=3366 and http://e4aws.silverdr.com/hacks/6500_1/

View on HN

The next sentence in the article,

> The researchers however disagreed with Intel's comments and reportedly said in an online discussion that the patched Intel firmware can be downgraded using Intel ME, making the chipset vulnerable and opening the door for accessing Intel VISA.

I agree that "physical access" is a threat that I'm not too concerned about¹. But the researchers don't seem to agree that that's the extent of the issue.

¹If physical access means "disassemble the case and do X". If physical access is "two seconds with an exposed USB port", then that's a different matter.

Rackable servers typically have a locking front cover to prevent that. You can buy CoverLocks for desktops.[0] This Kensington USB lock also looks interesting.[1] The keys are unique, by the way.

0) http://www.computersecurity.com/coverlock/

1) https://www.amazon.com/Kensington-Cable-Guard-Rectangular-K6...

I was shopping a few months back at a store with a particularly disinterested cashier who was doing something on their phone and was also charging it using the USB port that was on the register. It struck me as something that you probably shouldn't be able to plug your personal device into but that it is likely a common practice when nothing actually prevents it.

Made me wonder if an attack scenario would be feasible where compromised phones could be used for targeted attacks utilizing one of the USB vulnerabilities; essentially just laying dormant until the user plugs into something interesting to charge.

Assuming that: Physical access vectors are often deemed a low priority/less likely to be patched and that testing if an employee cares more about the BYoD security policy or their dying phone will have not favor infosec. It seemed like an interesting way to get access to point of sale systems that I had not heard anyone talk about before.

Some other privilege escalation vulnerability would have to be exploited go beyond the usual app malware capabilities but I don't know enough about USB or mobile OS's to know if it would be possible even with root(maybe that's why no one talks about it).

The main thing is "Why undocumented?", not threat model and physical or remote exploit.

Based on the name, the tool likely makes it easy for others to figure out low-level details of processor implementations that Intel would prefer be trade secrets.

Why undocumented? Because Intel is not RISC-V or even Arm. Do you expect other chip makers to document every internal detail of their chips? And yes, as chips grow in internal complexity, bugs like this one become inevitable - so perhaps we should be insisting on fully-documented designs.

There was nothing inevitable about this particular one, unless you mean it at the level of "people will always make mistakes and there's nothing you can do about it"

> The main thing is "Why undocumented?", not threat model and physical or remote exploit.

No, the main thing is if VISA is for qualifying chips on the production line, why don’t they burn a fuse permanently disabling it on chips that pass QA?

Yet another main question, because ...

VISA isn't for qualifying chips as much as it is for debugging chips including customer returns. Long ago access to limited versions of the signals was given to some customers under NDA and customers had the ability to set customer fuses which would prevent Intel from unlocking the debug features. There's also an unsupressable "debug enabled" bit hardwire to a lot of these functions if I remember so the parent system can always see if somebody turned on the debug functions. Turning on debug functions also usually had the effect of disabling/corrupting important key material.

This said, its basically a giant signal mux system run into a main block, you'd be pretty limited on what preselected signals are available at a time. People were also reasonably careful not to give entire busses of signals at once.

Testing/debugging features are intended for internal use only and can expose proprietary information about their implementation, so only Intel and possibly some motherboard manufacturers are allowed the knowledge.

Speaking of documentation, while not fully open, Intel/AMD are already ahead of many others when it comes to documenting things. Look at the SoCs used in smartphones and tablets, or the infamous Raspberry Pi. AFAIK, Intel is not in the business of making secure cryptoprocessors like the ones used in payment cards and SIMs, but once again even with those you are very unlikely to find public documentation --- everything is NDA'd.

That said, don't get me wrong, I'm not advocating for leaving things undocumented; just explaining how it usually turns out that way.

> Intel is not in the business of making secure cryptoprocessors like the ones used in payment cards and SIMs

They have entered a rather comparable space with stuff like TPM and SGX (and are largely using it for nefarious, consumer-hostile stuff like DRM and remote code attestation, of course).

You can also use SGX for privacy-preserving enclaves, which makes the combined existence and secrecy of this debugging stack more concerning.

Unless there are countermeasures that we don’t know about, this is a huge backdoor for such systems.

With DRM, the attackers afe consumers. With enclaves, the attackers are Intel and government intelligence agencies.

SGX always involved trusting Intel. It was Intel basically telling a third party "yup, this machine is running the binary code you expect it to be running". Which is exactly why it's nefarious, of course - a third-party has no business forcing me to run their proprietary binaries on my own machine in order to access their service. If they want that kind of trust, they're still free to establish that by sending me a physical dedicated-use device that can authenticate itself to whatever service they care about.

Hm, while I completely agree about not wanting proprietary garbage on my machine, I'm not sure about this logic. A third party can stipulate anything it likes, in order to use their service - you're always free not to use that service. Arguably, the ability to certify that you, the user, are indeed running the code you say you are is a feature provided to you, rather than a restriction imposed upon you. Not a feature I have interest in using, but nevertheless it's possible to frame it that way around. The fact that such code tends to be proprietary is (again, very arguably) besides the point.

> you're always free not to use that service

Unless that service has monopoly power. SGX makes it far too easy for an entity to abuse monopoly power, by directly turning it into power over what their customers have to run. This is why this sort of thing should only ever be done via physical devices - "monopoly" over a single, dedicated device is far more obvious and less insidious.

SGX only guarantees the isolated memory region remains isolated. It doesn’t guarantee the code running in it is secure or even leak-free. Microsoft Research has studies this and release a compiler for making stronger claims about code running inside the enclave but I think this is still very much an open problem.

You will always want layers of security and even then security is an illusion .... there will always be a way, just with different costs to exploit and thus risk/reward frontier.

The processor in a payment card doesn't have any valuable data that the bank doesn't already have, unlike computer's CPU.

> Am I the only one here who thinks "threat model" and isn't all too worried? Physical access = full control, I've long held that belief and am not happy that this freedom is continually being eroded in the name of ever-increasing ridiculous "security" (a lot of it against the user, for things like DRM, as mentioned in one of the other comments here.)

People care because that means that when you run something in the "Cloud(tm)" you have to trust the cloud provider.

The goal of things like "SGX" was so that you could run things on machines under someone else's control and still trust the results.

SGX doesn’t guarantee results, just isolation. You would still need a protocol for confirming that the code was error free, didn’t leak data, not to mention side channel attacks and timing analysis.

Oblivious RAM, FHE, ZKSNARKs are to be considered when you don’t trust the hardware, the users, the cloud, administrators, etc.

Some combo of TEEs, formal verification, binary verification, FHE, etc. might keep your data secure for a little while...maybe.

With encrypted drives and TPM you can still raise the bar pretty high before physical access means you have control. You may have control of the hardware, but not of what’s running inside.

Reply on news.ycombinator.com