Subject: Re: [ARM ATTEND] catching up on exploit mitigations
Date: Saturday 3rd August 2013 00:03:21 UTC (over 4 years ago)
On Tue, Jul 30, 2013 at 12:05:40PM -0700, Kees Cook wrote: > - vector table protections (needs to be protected like the x86_64 > vsyscall table, RO, etc) (Dropped some mailing lists to reduce the visibility of this as its soo close to the patches being merged...) On the subject of this, those who are following what's going on at the blackhat conference will be aware that there was a presentation yesterday on this very subject. Now that the presentation has been done, and the fixes are now merged into Linus' tree, I can now talk about this. There seems to be some confusion about the vector page - there are some people who claim that the vector page is writable from userspace. They are simply wrong - no mainline kernel has ever had wriable vectors from userspace. That would be one hell of a big security hole. However, there is a concern that the vector page reveals too much information to userspace about the kernel, possibly giving away the location of the syscall table, and whether the exposed code in that page could be used to assist exploits of user applications - effectively making ASLR useless. This has been mitigated as much as reasonably possible; the signal return code is now in a page which is placed randomly into the user address space - and the signal handlers are placed randomly within that page, and the page poisoned with a faulting instruction on both ARM and Thumb. The vector page is also poisoned in a similar manner; any attempt to execute non-intentional code in that page will result in a SIGILL. The code fragments which are jumped to by the instruction at the vector location is now moved to a following page, which is inaccessible to userspace. All userspace can see there now is a set of branches to the following page, not the branches into the kernel image. The kuser helpers are an all together much bigger problem, because they're part of our userspace ABI. Don't go thinking that modern builds don't call them, because they do, even when the builds are optimised for ARMv7, as I can demonstrate with Ubuntu 12.04.1 ARMHF. The get_tls helper still sees quite an amount of calls to it. However, the option is given to the guy configuring the kernel to disable these and make the vector page inaccessible to userspace. When the page is made inaccessible to userspace, it becomes read-only on the kernel side too. The down side of this is the user ABI breakage, so it can only be done _if_ you're sure that you have absolutely no users of that stuff and none of your 3rd party stuff does either (iow, think Android apps). Some other solutions were considered, such as trapping faults to the page and emulating the code that was there; given the amount of use this stuff gets, I believe that would have a noticable performance impact. I also considered making the vectors page inaccessible to userspace based on a kernel command line parameter - that's something we can add if people want that. As this issue in itself does not lead to the kernel being exploitable, I view this as a fairly minor security issue; these patches are just hardening the system against possible abuse, just like ASLR theoretically makes it harder.