Some Bad Fiasco
happend during 2009; a lot of security-problems occured in the linux-kernel due to null_pointer_dereference_bugs, leading to local Denial-Of-Service of single services, the whole system, or, even worse, to local Privilege-Escalation, meaning a normal user can gain root with executing just some small exploits[18]; see refs [1]-[6][37].
issues regarding null_pointer_dereference_bugs had been reported earlier[21]-[24], but finding and publishing a bug[5] that is included in all kernel-version from 2.4 (released in 2001) up to today gets a lot of kudos, as well as the exploits that came shortly after[18]; one could hear that loud “OoooOOOuuups” throughout the datacenters …
but whats the case with this null_pointers and mmap_min_addr? some articles and diskussions [5][9][36] explains the issue very detailed, here is a quote from a wiki.debian.org-entry[28]:
"mmap_min_addr is a kernel tunable that specifies the minimum
virtual address that a process is allowed to mmap. Allowing
processes to map low values increases the security implications
of a class of defects known as "kernel NULL pointer dereference"
defects. If a malicious local user finds a way to trigger one of
these NULL pointer defects, they can exploit it to cause system
hangs, crashes, or otherwise make parts of the system unusable.
If this user is also able to map low portions of virtual memory, they
can often further exploit this issue to gain increased privileges."
although you mostly need a local account to exploit such bugs you shouldnt think: i have no user-logins, i have no problem[11][14]. especially if you run public accessible servers it's better to avoid ANY kind of secruity problems. Why this kind of bugs is dangerous and a big threat to any linux-machine states a good discussion[19]: it looks like, if your run any vulnerable service on an accessible server you can get r00ted for nuts; it is .
the linux-kernel is probably full of that stuff; one of the uglier bugs[5] was found in all kernel_version from 2.4 upwards; thats 8 years. the bugs are patched as fast as they are found, but this looks more like a design_error within the kernel itself, not just a compiler-problem. the issue is known by the kernel-maintainers and changed in jun for the mainline-kernel 2.6.30.2[34], but the distro_vendors are askeds to take actions too to provide updated kernels for older/stable distributions.
what to do
first, keep your machines updated; there's a good chance your distro_vendor have patches available.
if you run servers you have to monitor the updates, released by your os-vendor and update early, update often, for the sake of your customers.
to check your actual value for mmap_min_addr:
cat /proc/sys/vm/mmap_min_addr
if it IS “0” then your system is vulnerable to a vary of null_pointer bugs.
fortunatly there is an easy workaround[7][9] that protects your linux_system (if not already done by the distro_makers by default) with two simple commands … but not always (see kernel/vendors below). if it works to set your system_wide value for mmap_min_addr then you're done; if not, you may have a problem.
the following commands will fix the problem, beyond reboot and independed from the linux_distro:
echo "vm.mmap_min_addr = 4096 " >> /etc/sysctl.conf && sysctl -p # another way is (non_permanent) sysctl -w vm.mmap_min_addr="4096"
if you run a debian_based system (although the above works fine on lenny) you might want to try the workaround from the debian_wiki:
# echo "vm.mmap_min_addr = 4096" > /etc/sysctl.d/mmap_min_addr.conf # /etc/init.d/procps restart
… life could be so easy …
problems with some kernels
on some older machines (see list below) the following might happen:
[ root@srv :~] > uname -r 2.6.18-6-xen-686 [ root@srv :~] > echo "vm.mmap_min_addr = 4096 " >> /etc/sysctl.conf && sysctl -p error: "vm.mmap_min_addr" is an unknown key ... shit ...
regarding older kernel, the debian_wiki states:
"The 2.6.18 kernel in Debian 4.0 ('etch') does not support
this kernel tunable. To obtain this safeguard, it is recommended
that users install the 2.6.24 "EtchAndAHalf" kernel, or upgrade
your systems to Debian 5.0 ('lenny'). "
(thanks dann.frazier@debian for the update)
... shit again ...
that means, if your run an old kernel where mmap_min_addr is not tunable you need to get updates from your distro_vendor for that kernel … if not you SHOULD UPGRADE! except, you know exactly what you do … the day might come where the first via network exploitable null_pointer_bug will be published.
vendor_specific informations (order by arrival.date DESC)
first, the two vendors of enterprise-linux (redhat and novell) have updated packages, but you need to turn on that feature by yourself; i can understand that for compatibility-reasons. second, i do care mostly on server-OS, means rhel/sles/centos/debian stable. no, opensuse is not a serveros, but (sic!) widely used in germany by hosters as server-os … no shit, sherlock!. thats why i covered it here.
- slackware[31]/gentoo[32][33]/sidux[35]/mandriva info added (not tested, read about it here[31] )(nov 14)
- novell SLES10sp2 is vulnerable and needs update to sles10sp3 (thanx m.meissner@suse) (nov 12)
- novell suse announces that SLES11/opensuse 11.x are save by default, since mmap_min_addr ist set to 4096[29]; tests shown that (some) opensuse_11.0_installations are NOT protected(a), whereas opensuse 11.1 is ok (nov 11)
- the actual updated fedora-11 is safe by default (nov 09)
- Redhat releases updated kernels for RHEL4 [27] with default for mmap_min_addr set to “0”, but also some documentation [26] on how to change that value
- RHEL5 has the kernel_option mmap_min_addr = 4096 by default [38][25]
- the actual sidux is safe by default[35] (nov 04)
- Redhat releases updated kernels for RHEL3 [25] sets the option mmap_min_addr, but must be set manually > 0 (see above) (nov 03)
- the actual centos_distro (centOS 5.4, dated oct 2nd) has mmap_min_addr = 4096 by default
- debias is aware of that problem[15], fixed the bugs and will deliver the updated stable-release from 5.0.4, which is expected in nov/2009, with mmap_min_addr = 4096 as default[20] (oct 23)
- redhat brings a workaround[12] for some bugs, discovered in august (hmm, yummy, remoteroot due to this sctp-bug)
- redhat has published and updates (nov 05) a document[40] on the issue “Security-Enhanced Linux (SELinux) policy and the mmap_min_addr protection ”
- novel (SLES/opensuse) has updated kernel_sources on some issues[16][17] but gives no advise about mmap_min_addr - value
- a) ⇒ it looks like this could be a problem from a german hostingprovider, running customized suse-11-versions with some strange kernels, that never gets updated … geee … more infos on that later, when i receive an answer from the company
list of checked distros/versions as of nov 2009
the following list gives an overview of the kernel_option vmmap_min_addr and its default_value for some llinux-distros and is only valid with security_patches applied, dated ~ nov 12 2009. it just shows if your system is vulnerable to null-pointer-dereference-bugs, NOT if your system is secure and bug_free!
| xxx | name | kernel/ok | kernel/not ok | default_value | actions needed |
|---|---|---|---|---|---|
| +/- | debian/lenny | 2.6.26-2-xen-686 | - | 0 | yes, see above |
| +/- | debian/lenny | 2.6.26-2-686 | - | 0 | yes, see above |
| +/- | debian/lenny | 2.6.26-1-686 | - | 0 | yes, see above |
| -_- | debian/lenny | - | 2.6.22-3-686-bigmem | 0 | use customized kernel/newer kernel > 2.6.24 |
| -_- | debian/etch | - | 2.6.18-6-xen-686 | xxx | update to lenny or use customized or kernel > 2.6.24 |
| ++ | suse/11.2 | 2.6.31.5-0.1-default | - | 65536 | no, nice distro  |
| ++ | suse/11.1 | 2.6.27.7-9-default | - | 4096 | no, nice distro |
| +/- | suse/11.0 | 2.6.27.21 | - | 0 | yes, see above (a) |
| -_- | suse/10.2 | - | 2.6.18.8-0.13-default | xxx | update or use a customized/newer kernel > 2.6.24 |
| -_- | suse/10.1 | - | 2.6.16.53-070731a | xxx | update or use a customized/newer kernel > 2.6.24 |
| ++ | sles/11 | 2.6.27.37-0.1-default | - | 65536 | no, nice distro |
| +/- | sles/11 | 2.6.27.19-5-default | - | 0 | yes, see above |
| -_- | sles/10sp2 | - | ??? | xxx | needs other kernel ⇒ sles10sp3 {~} |
| +/- | sles/10sp3 | ??? | - | 0 | yes, see above {~} |
| +/- | rhel/3 | ??? | - | 0 | yes, see above {~} |
| +/- | rhel/4 | ??? | - | 0 | yes, see above {~} |
| ++ | rhel/5 | 2.6.18-164.el5 | - | 4096 | no, nice distro |
| ++ | rhel/5 | 2.6.18-164.6.1.el5 | - | 4096 | no, nice distro |
| ++ | centos/5.4 | 2.6.18-164.el5 | - | 4096 | no, nice distro |
| ++ | fedora/11 | 2.6.29.4-167.fc11.i586 | - | 65536 | no, nice distro |
| ++ | gentoo/actual build | 2.6.xxx | - | 4096 | no, nice distro {~} |
| ++ | slackware/12.1 | 2.6.xxx | - | 4096 | no, nice distro {~} |
| ++ | slackware/12.2 | 2.6.xxx | - | 4096 | no, nice distro {~} |
| ++ | slackware/13 | 2.6.xxx | - | 4096 | no, nice distro {~} |
| ++ | siddux/actual | ??? | - | 4096 | no, nice distro {~} |
| ++ | mandriva/09-10 | ??? | - | 4096 | no, nice distro {~} |
- xxx ⇒ no tunable mmap_min_addr possible, exploitable[18] by default
- ++ ⇒ safe per default, not exploitable through null_pinter_bugs
- +/- ⇒ mmap_min_addr is tunable, but not safe by default; must be set manually
- -_- ⇒ AUTSCHN[30] .. kernel has no tuning-option, update often, update early if you vendor doesnt supports this kernel anymore with security_updates you should upgrade asap
- {~} ⇒ vendor-information, otherwise tested
Remarks: i only checked for the existance of mmap_min_addr and its default_value; i didn't checked on every platform it some of these widely-spread womballa_empire or other exploits worked; see luxzifer_tests below
the SELINUX - issue
in august[41] one of the null_pointer_bugs led to a complete compromise even of SELINUX-secured systems, that not should have happened anyway.
redhat released two documents[26][40], dealing with the issue, updates in sep and nov[40][42].
again: if you run servers you have to monitor the updates, released by your os-vendor and update early, update often, for the sake of your customers.
luxzifer_tests
after reading some interesting note from brad spengler[38] i started to test his enlightenment_stuff on some serverstups, patched and unpatched, with mmap_min_addr set to 0 and 4096. enlightenment is a nice exploit-collection from the guy mentioned above, working on non-patched systems (non-patched in the meaning of: no kernel_security_patches applied within the last 2 months) or unpatched standard-installations, as far as i could test, especially if vmmap_min_addr is set to 0.
.
| system | kernel | mmap_val | remarks | XxX |
|---|---|---|---|---|
| rhel5 | 2.6.18-164.el5 | 4096 | standard install from a downloaded version (nov 12), no security patches | no |
| rhel5 | 2.6.18-164.el5 | 0 | standard install, no security patches | YEZ |
| rhel5(b) | 2.6.18-164.6.1.el5 | 4096 | standard install WITH actual security patches (nov 16) | no |
| rhel5 | 2.6.18-164.6.1.el5 | 0 | standard install WITH actual security patches (nov 16) | no |
| debian/lenny | 2.6.26-2-686 | 4096 | standard install WITH actual security patches (nov 16) | no |
| debian/lenny | 2.6.26-1-686 | 4096 | standard install with patches from march | no |
| debian/lenny | 2.6.26-1-686 | 0 | standard install with patches from march | YEZ |
| suse/11.1 | 2.6.27.7-9-default | 4096 | standard install with no security patches (download_version dec 2008) | no |
| suse/11.1 | 2.6.27.7-9-default | 0 | standard install with no security patches (download_version dec 2008) | YEZZ |
| suse/11.1 | 2.6.27.7-9-default | 4096 | standard install with no security patches (download_version dec 2008) | no |
| suse/11.1 | 2.6.27.7-9-default | 0 | standard install with no security patches (download_version dec 2008) | YEZZ |
| sles/11 | 2.6.27.19-5-default | 0 | standard install with no security patches (nov 12) | YEZZ |
| sles/11 | 2.6.27.19-5-default | 4096 | standard install with no security patches (nov 12) | no |
screenshots
RHEL
DEBIAN
opensuse
SLES
problemes with some apps
the following apps are know to fail[9] if mmap_min_addr is set > “0”:
- wine
- dosemu
- quemu
- SELINUX???
lookout
it seems (and i hope) like the distro_vendors (see vendor_specific informations above) will change the default_value for mmap_min_addr to > 0, if not done already (suse, slackware), or at least provide kernels with mmap_min_addr as tunable value for admins to decide wether to leave this for compatibility reasons or not.
but this wouldn't prevent us from stupid admins that never patch their systems, (sic!)
credits (in order of apperance)
- marcus meissner from opensuse for his fast and informative support
- that nice guy on the redhat-hotline who helped me with fast downloads while the eval-download-page was broken and the support-telephonenumbers on the german website were wrong
- brad sprengler from grsecurity.org for wunderbare exploits and usefull hints
- dba for correcting some akwward tysop
- …
References
- [14] http://www.phocean.net/2009/08/17/opensuse-kernel-sources-patching-against-’sock_sendpage’-null-pointer-dereference-vulnerability.html
- [18] womballa_empire
- [32] this maybe a hint that the default_value is changed in gentoo too? dont have the time to compile that … http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.30.2
- [34] search for: “commit e0a94c2a63f2644826069044649669b5e7ca75d3 upstream.” to find the commit ⇒ http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.30.2
updates
- 2009-11-17 - SELINUX-issue, typos and more references
- 2009-11-16 - luxzifer_tests
- 2009-11-14 - found some infos on slackware, gentoo, mandriva, sidux
- 2009-11-12 - more infos from novell/suse regardings sles10 (thanx m.meissner@opensuse)
- 2009-11-12 - found some strange settings on a german hoster
- 2009-11-11 - updates on novel/suse-specific informations (thanx m.meissner@opensuse)
- 2009-11-08 - found more stuff and links, esp. on redhat
- 2009-11-06 - initial version