Check `suid` against CacheWarp

[hilbix]

The problem is when the initialized value equals the privileged value.

sudo can be attacked this way. It is very likely that suid is affected, too, because root has UID=0.

I have no good idea how to mitigate this, as static data segments always use 0.

Two ideas about this:

• registers are not affected by cache
• stack can be primed with random information thanks to subroutines
  • however the stack probably can still be taken from a time when it was NUL

[hilbix]

See also https://cachewarpattack.com/#faq

Does CacheWarp affect traditional virtual machine isolation?

No, CacheWarp only affects AMD SEV, as traditional virtual machines do not offer any protection against malicious hypervisors.

This bug only affects VMs running in AMD SEV,
so it only affects very few setups and therefor I will not put much effort into this (read: It has a very low priority for me).

The problem is, that I cannot test this, as I am apparently too dumb to grok how to do AMD SEV with my available hardware, sorry.

I tired to understand https://documentation.suse.com/sles/15-SP3/html/SLES-all/article-amd-sev.html but failed to adapt this properly to my environment:

root:~# virsh capabilities | grep -i sev
root:~# grep -i sev /proc/cpuinfo
root:~# dmesg | grep -i sev
root:~#

I am even not sure that this is how to check for SEV being present in the CPU, as apparently how to do that is a very well hidden secret.

The first thing I would expect in the information is
how to check that the CPU is SEV capable at all.

But I am unable to find an official source.
Hence the above was done with the help of StackOverflow.

But my experience shows, that more than 90% of StackOverflow,
either is completely wrong, misleading, highly dangerous
simply circumvents the problem instead of solving it,
or is a combination of all of these alltogether.

Hence my latest available AMD processor here apparently does not support this feature, so I cannot even test for it.

What I need to mitigate this:

• Access to a machine with SEV support
• Some VM running within SEV
• An exploit demonstration with an always successful attack against some carefully written test program
• A mitigation for the test program which then thwarts the attack
• Create a special testing suid variant which replicates what the test program did to be always successfully exploitable
• mitigate this in the special version of suid
• strip down the mitigation such that it fits into normal suid

And then:

• Create an attack against the standard suid
• Do a brute force attack against the original suid to find it vulnerable
• Confirm that the patched version of suid resists this attack

Note that the brute force against the patched version must run around 6 to 12 months on 100% CPU on at least 16 cores to be considered successful.

Also I probably must get into some deep understanding of SEV, SME and CacheWarp.

All in all I do not think that this mitigation takes a few weeks (around 200 to 800) work. Or in money equivalents, fixing this bug will cost around est. 50000 EUR. With the risk, that the outcome is that it is near to impossible to protect suid against CacheWarp or it even it is very unlikely that CacheWarp can be successfully mounted against suid at all.

[hilbix]

So before even considering this bug any deeper, first there must be some valid information that CacheWarp can be indeed used to attack suid and that there is a valid way to protect against this type of attack.

This includes the first 4 steps noted above:

To create a test program which can be exploited, and then implement a fix on the program such, that the exploit does no more succeeds.

If this is done, then I can revisit this bug again.