Intel AMT Hit By Another "Critical" Security Vulnerability

[phoronix]

Phoronix: Intel AMT Hit By Another "Critical" Security Vulnerability

Intel's September 2020 security advisories were posted today and include four security advisories around nine vulnerabilities...

http://www.phoronix.com/scan.php?pag...INTEL-SA-00404

[onlyLinuxLuvUBack]

Say it aint so.

[KoenDG]

It keeps happening.

[wswartzendruber]

This trick is getting old. Can't they do something else impressive?

[NotMine999]

Intel security flaws ... the gift that keeps on giving ... no matter how many times you refuse delivery.

[abott]

Closed source programs showing why mission critical things should never have a single line of code no reviewed by peers. This is gonna go back forever in terms of performance hits and privacy concerns.

Imagine how many computers waiting to be hacked in Russia depended on this shit to crack it? We fucked ourselves by being that careless of how our products work and accepting of business-class "security."

Can only trust closed source software as much as you can see its workings. Can't see it at all, it's untrustable.

[torsionbar28]

Total takeover of the machine, by an unauthenticated remote user, yowsa that's bad. Not a good look Intel, but at least you're consistent!!

[Luke]

Intel security flaws ... the gift that keeps on giving ... no matter how many times you refuse delivery.

You can only refuse delivery by not buying the offending products-and THAT just seems to get harder and harder. By the time all this is unwound, performance of a 4 core hyperthreaded chip becomes that of a cluster of four of the original Pentium with a die shrink, a 4GHZ clock speed, and a few MB of on-die cache. That's assuming we can safely run multiple cores in a security-sensitive contest.

Real world we might have to totally separate sensitive and insensitive work. When a passphrase is called for or encrypted content is being encrypted, decrypted, or sent over the net suspend all other programs, evict the cache, shut down all but one thread of one core, finish the sesitive job, then evict all its content from cache and start the other jobs back up. Oh yeah: use separate areas in RAM too.

Maybe a better fix allowing simultanious operation of such tasks might be to create new microcode for Intel IME/AMD PSP (with open and auditable source) to allow offloading the sensitive stuff to that already present simple, (presumably) in-order, single-thread proc separate in hardware from the main CPU. Once you disable all the stuff requiring mitigations, that core should be nearly as powerful as the main cores except for clock speed anyway. That way such things as key and passphrase handling can be simply kept all the way off the main CPU and all of its registers, cache, etc. Main CPU never touches encryption, and never use the same physical CPU anymore for two or more mutually untrusting users. That of course would mean any sensitive, non-self hosted website needs one whole CPU chip on the server unless it is possible to just old-style timeshare a chip, with all data evicted back to RAM and zeroed out in the cache between users.

[torsionbar28]

You can only refuse delivery by not buying the offending products-and THAT just seems to get harder and harder. By the time all this is unwound, performance of a 4 core hyperthreaded chip becomes that of a cluster of four of the original Pentium with a die shrink, a 4GHZ clock speed, and a few MB of on-die cache. That's assuming we can safely run multiple cores in a security-sensitive contest.

Real world we might have to totally separate sensitive and insensitive work. When a passphrase is called for or encrypted content is being encrypted, decrypted, or sent over the net suspend all other programs, evict the cache, shut down all but one thread of one core, finish the sesitive job, then evict all its content from cache and start the other jobs back up. Oh yeah: use separate areas in RAM too.

Maybe a better fix allowing simultanious operation of such tasks might be to create new microcode for Intel IME/AMD PSP (with open and auditable source) to allow offloading the sensitive stuff to that already present simple, (presumably) in-order, single-thread proc separate in hardware from the main CPU. Once you disable all the stuff requiring mitigations, that core should be nearly as powerful as the main cores except for clock speed anyway. That way such things as key and passphrase handling can be simply kept all the way off the main CPU and all of its registers, cache, etc. Main CPU never touches encryption, and never use the same physical CPU anymore for two or more mutually untrusting users. That of course would mean any sensitive, non-self hosted website needs one whole CPU chip on the server unless it is possible to just old-style timeshare a chip, with all data evicted back to RAM and zeroed out in the cache between users.

yawn, let us know when you have a working prototype.