Messages in this thread | | | Date | Thu, 25 Jan 2018 18:11:42 -0800 (PST) | From | Liran Alon <> | Subject | Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation |
| |
----- dave.hansen@intel.com wrote:
> On 01/23/2018 03:13 AM, Liran Alon wrote: > > Therefore, breaking KASLR. In order to handle this, every exit from > > kernel-mode to user-mode should stuff RSB. In addition, this > stuffing > > of RSB may need to be done from a fixed address to avoid leaking > the > > address of the RSB stuffing itself. > > With PTI alone in place, I don't see how userspace could do anything > with this information. Even if userspace started to speculate to a > kernel address, there is nothing at the kernel address to execute: no > TLB entry, no PTE to load, nothing. > > You probably have a valid point about host->guest, though.
I see it differently.
It is true that attacker cannot speculate to a kernel-address, but it doesn't mean it cannot use the leaked kernel-address together with another unrelated vulnerability to build a reliable exploit.
Security is built in layers. The purpose of KASLR is to break the reliablity of an exploit which relies on vulnerability primitives such as: memory-corruption of a kernel-address, hijack kernel control-flow to a kernel-address or even just read a kernel-address. In modern exploitation, it is common to chain multiple different vulnerabilities in order to build a reliable exploit. Therefore, leaking a kernel-address could be exactly the missing primitive to complete a vulnerability-chain of a reliable exploit.
I don't see a big difference between leaking a kernel-address from user-mode vs. leaking a hypervisor-address from guest. They are both useful just as a primitive which is part of an exploit chain.
One could argue though, that currently KASLR is fundementally broken and therefore should not be considered a security boundary anymore. This argument could be legit as there were some well-known techniques that could break KASLR before KPTI patch-set was introduced (e.g. Timing memory accesses to kernel-addresses and messure reliably by leveraging TSX). Another well-known argument against KASLR is that it is a non-deterministic mitigation which some argue is not good enough. However, I think that if we decide KASLR is not a security boundary anymore, it should be made loud and clear.
In general, I think there are some info-leak vulnerabilities in our current mitigation plan which doesn't seem to be addressed. I will be glad if we could address them clearly. These are all the open issues as I see them:
1) Because IBRS doesn't restrict low prediction-mode code from using BTB of high prediction-mode code, It is possible to info-leak addresses from high prediction-mode code to low prediciton-mode code. This is the KASLR breakage discussed above. Again, could be ignored if we discard KASLR as a security boundary.
2) Both IBRS & retpoline don't prevent use of BHB of high prediction-mode code from being used by low prediction-mode code. Therefore, low prediction-mode code could deduce the conditional branches taken by high prediction-mode code.
3) Similar leak to (1) exists from the fact that RSB entries of high prediction-mode code could be leaked by low prediction-mode code which may reveal kernel-addresses. Again, we could decide that this isn't a security boundary. An alternative to solve this could be to just stuff RSB from a fixed address between prediction-mode transitions.
-Liran
P.S: It seems to me that all these issues could be resolved completely at hardware in future CPUs if BTB/BHB/RSB entries were tagged with prediction-mode (or similar metadata). It will be nice if Intel/AMD could share if that is the planned long-term solution instead of IBRS-all-the-time.
| |