| |||||||||||||
Another kernel NULL pointer vulnerabilityAnother kernel NULL pointer vulnerabilityPosted Aug 14, 2009 5:36 UTC (Fri) by spender (subscriber, #23067)In reply to: Another kernel NULL pointer vulnerability by lkundrak Parent article: Another kernel NULL pointer vulnerability
See my post in the other thread. There's a vulnerability in SELinux where it overrides the mmap_min_addr setting, where by default on all RHEL installs, any logged in user is able to mmap at 0, regardless of the mmap_min_addr setting. My exploit still works on the latest RHEL kernel.
-Brad
(Log in to post comments)
Another kernel NULL pointer vulnerability Posted Aug 14, 2009 11:09 UTC (Fri) by jamesmrh (guest, #31622) [Link]
Just to clarify, the problem arises from the policy shipped in RHEL5, not in SELinux itself.
Eric Paris posted on the topic here:
http://eparis.livejournal.com/606.html
(see comments for further thoughts from Brad).
Note that the LSM and SELinux logic has been reworked upstream by Eric. The primary patch of interest is:
http://marc.info/?l=linux-security-module&m=124905958...
This will allow finer control over the ability to perform low mappings with better separation of DAC and MAC controls & will be pushed to Linus for 2.6.32.
Another kernel NULL pointer vulnerability Posted Aug 14, 2009 17:43 UTC (Fri) by MarkWilliamson (guest, #30166) [Link]
> Just to clarify, the problem arises from the policy shipped in RHEL5, not
> in SELinux itself.
I had the impression from previous LWN articles that there was also a bug or, at least, an "unintended feature" in the LSM infrastructure (not specifically SELinux, then), which disabled the normal Linux checking for minimum mmap-able address when an LSM was installed.
So one *aspect* of the problem is affected by the presence of SELinux (or other LSMs), even though SELinux itself may not contain the bug. Is that correct too?
Another kernel NULL pointer vulnerability Posted Aug 14, 2009 18:00 UTC (Fri) by spender (subscriber, #23067) [Link]
Yea, they used a bunch of weasel words like "dumb idea"/"stupid behavior" etc instead of calling it what it was: a vulnerability. I hear finally they are going to call it as such and issue a CVE (and then hopefully actually resolve the problem, which is currently unfixed). And it only took them an entire month, having my CVE request ignored, releasing two exploits, one of which works against all Red Hat/Fedora/RHEL versions since 2001, having them lie about putting in their own CVE request (they asked me to cancel my CVE request so they could put their own in) to have it pushed aside as an "errata" and then ultimately left unfixed.
-Brad
Another kernel NULL pointer vulnerability Posted Aug 15, 2009 11:39 UTC (Sat) by trasz (guest, #45786) [Link]
In this case, it's more a design mistake in LSM - allowing a policy to _lower_ the security, i.e. to permit something that would be otherwise denied - than a specific vulnerability. Vulnerability is just an effect of this problem.
Another kernel NULL pointer vulnerability Posted Aug 15, 2009 9:36 UTC (Sat) by jamesmrh (guest, #31622) [Link]
The fact that it's possible at all to have weaker security with MAC enabled is a design problem in itself. LSM/SELinux doesn't disable the check inherently, but it allows a policy writer to inadvertently do so, which is what we're addressing upstream.
The SELinux policy in RHEL5 for unconfined domains (i.e. local logged in users) has no check. Eric's changes will allow the MAC and DAC checks to be properly separated, so SELinux policy can't override DAC in this case. (See Eric's blog entry, it has a much more thorough explanation).
Another kernel NULL pointer vulnerability Posted Aug 15, 2009 14:34 UTC (Sat) by jimmybgood (guest, #26142) [Link]
Yes, I read Eric's blog. He's being disingenuous by claiming that while SELinux might have allowed a local user to escalate privilege, it would have been more resistant to a network attack. That might have been true in July, but it wasn't true in early August when this exploit was reported.
Having patched my kernel to 2.6.30.4 in July, this exploit would not run, with vm reporting that the page couldn't be mapped.
The problem is that SELinux is too difficult to configure forcing even quite knowledgeable sysadmins to rely on canned distro configurations, which may or may not be suitable for their particular need. In many situations (where WINE was needed), SELinux _was_ doing the right thing.
The same can be said of the hal, console-kit and policykit consortium. I'd feel more comfortable with an X server running as root, than the new unprivileged X, with hal and friends. The only way I can configure hal is to google a magic invocation and cross my fingers. I'll bet we'll see major exploits using hal, ck and/or pk coming soon.
I'm not sure what the solution is. My work around is to avoid any security solution that I can't comfortably configure and feel that I understand fully what I'm doing. That's never been the case with SELinux. I know there's a parser that will look at the logs and give you a configuration snippet, but I don't know how it works and so I don't trust it.
Another kernel NULL pointer vulnerability Posted Aug 15, 2009 16:15 UTC (Sat) by nix (subscriber, #2304) [Link]
Even the new unprivileged X can have HAL entirely compiled out of it :)
Another kernel NULL pointer vulnerability Posted Aug 14, 2009 18:07 UTC (Fri) by spender (subscriber, #23067) [Link]
SELinux could have obeyed the mmap_min_addr restriction, and further tightened it down (as not all things with CAP_SYS_RAWIO need to mmap at 0). If SELinux was doing the right thing from the beginning, the code wouldn't need any "reworking."
-Brad
|
|||||||||||||