James Morris - mmap_min_addr setting may mitigate vmsplice exploit
mmap_min_addr setting may mitigate vmsplice exploit|
Rafal Wojtczuk of McAfee Avert Labs posted an interesting analysis of the "qaaz" exploit for the recent vmsplice vulnerabilities.
Since 2.6.23, it has been possible to prevent applications from mapping low pages (to prevent null pointer dereferencing in the kernel) via the /proc/sys/vm/mmap_min_addr sysctl, which sets the minimum address allowed for such mappings.
So, if you have a recent kernel still affected by the vmsplice issue, try:
echo 65536 > /proc/sys/vm/mmap_min_addr
(If it is not already set, of course).
If using SELinux, the system must be running in enforcing mode.
Note that there was a bug in the mmap_min_addr code until 2.6.24-rc5, although I do not believe it affects mitigation of this particular exploit.
Generally, it is a good idea to have mmap_min_addr set, although it is disabled by default in the upstream kernel as it can affect a some applications (e.g. users of vm86 mode such as X).
As SELinux is able to selectively enforce the setting via policy, it can be enabled for the general case on recent SELinux systems. If not using SELinux, processes with CAP_SYS_RAWIO are allowed to bypass the setting.
Tags: linux, mitigation, selinux, vulnerabilities
|Date:||February 14th, 2008 11:01 pm (UTC)|| |
you're wrong (pickle surprise!)
Sorry, but Rafal's analysis is wrong for the exploit on a 64-bit kernel, mmap_min_addr will do nothing for you there. Luckily, as you only seem to care about the "default" version of these public exploits, the 64-bit version of the exploit is broken -- it works with a small change.
And this "bug" that you dismiss so easily (which had been known of privately ever since mmap_min_addr was devised) makes this vulnerability trivially exploitable with a two-line change that any attacker with half a brain can accomplish. For those with less than half a brain: mmap above the mmap_min_addr limit with MAP_GROWSDOWN and force a page-by-page expansion down to 0.
And of course, other avenues of exploitation haven't been ruled out, as there is a lot of code that executes before the attacker-controlled fptr is dereferenced (which causes the system instabiliity even if the "exploit" is prevented).
Note that I said "may" and referred to the specific exploit which is readily available. This approach may be useful for people with no other current solution, and it also demonstrates the potential usefulness of mmap_min_addr for mitigating vulnerabilities (given that it's set to zero on all current distros, its importance was likely not understood).
|Date:||February 14th, 2008 11:43 pm (UTC)|| |
> given that it's set to zero on all current distros, its importance
> was likely not understood
or more likely, it was and noone found it funny to break valid userland applications. for a proper solution you'd need something like UDEREF does in PaX.
cheers, PaX Team