![Security Security](http://a.fsdn.com/sd/topics/security_64.png)
![Linux Linux](http://a.fsdn.com/sd/topics/linux_64.png)
Bug In Most Linuxes Can Give Untrusted Users Root 281
Red Midnight and other readers brought to our attention a bug in most deployed versions of Linux that could result in untrusted users getting root access. The bug was found by Brad Spengler last month. "The null pointer dereference flaw was only fixed in the upcoming 2.6.32 release candidate of the Linux kernel, making virtually all production versions in use at the moment vulnerable. While attacks can be prevented by implementing a common feature known as mmap_min_addr, the RHEL distribution... doesn't properly implement that protection... The... bug is mitigated by default on most Linux distributions, thanks to their correct implementation of the mmap_min_addr feature. ... [Spengler] said many other Linux users are also vulnerable because they run older versions or are forced to turn off [mmap_min_addr] to run certain types of applications." The register reprints a dialog from the OpenBSD-misc mailing list in which Theo De Raadt says, "For the record, this particular problem was resolved in OpenBSD a while back, in 2008. We are not super proud of the solution, but it is what seems best faced with a stupid Intel architectural choice. However, it seems that everyone else is slowly coming around to the same solution."
First post (Score:5, Insightful)
But you don't know if I didn't just hack the servers ;)
Re: (Score:2)
If you have an inane first post and +5 Insightful mod, then I'll believe you hacked the server...
Isn't this a dupe? (Score:2, Insightful)
Surely this [slashdot.org] is the same story, from 2 months ago.
Re:Isn't this a dupe? (Score:5, Informative)
Just type sysctl -w vm.mmap_min_addr=4096 in your box (or any other number > 0) and you are safe.
Re: (Score:3, Informative)
This is from Fedora running kernel 2.6.30 with minimal customization (almost default, and no tweaking related to this one):
$ cat /proc/sys/vm/mmap_min_addr
65536
The devs seem to be doing an adequate job to mitigate this problem.
Re:Isn't this a dupe? (Score:5, Informative)
$ sysctl -n vm.mmap_min_addr to find what your setting is.
On Ubuntu 8.04 LTS servers (including Xen kernels) and on 9.10 desktops it is 65536. Not a big deal.
http://wiki.debian.org/mmap_min_addr [debian.org]
https://lists.ubuntu.com/archives/ubuntu-devel/2008-July/025805.html [ubuntu.com]
http://www.securityfocus.com/bid/26831/info [securityfocus.com]
Re: (Score:3, Insightful)
Ran off my Ubuntu 9.10 fresh installed desktop:
#cat /proc/sys/vm/mmap_min_addr ... Oh shit.
0
Re: (Score:3, Interesting)
Ran off my Ubuntu 9.10 fresh installed desktop:
#cat /proc/sys/vm/mmap_min_addr
0 ... Oh shit.
Is it possible that you are running wine or some other emulator program. The only software similar to an emulator I have is Virtualbox on my 9.10 desktop and it still has the 65536 setting.
Anyone else can shed light on this?
Re: (Score:3, Informative)
I have VirtualBox and Wine, and VirtualBox uses a kernel module. So it's possible that one of those could have set it to 0. I set it to 65000 just in case and it didn't break Wine or VirtualBox...
Re: (Score:3, Informative)
I have two machines with Open SuSE 11.1 One returns 0, and the other 65535. The one returning zero runs only samba and apache (+webdav module for an ical server). The one returning 65535 runs samba and xen.
Re:Isn't this a dupe? (Score:5, Informative)
Ubuntu sets this to zero if you have wine installed.
So it's a windows bug (Score:5, Funny)
So it's a windows bug.
Re: (Score:3, Informative)
Re:Isn't this a dupe? (Score:4, Informative)
Re: (Score:2)
I have both VBox and Crossover Office running on 8.10 desktop. I also get 65536 back from that command. Using kernel 2.6.27-15 generic x86_64 No, I didn't tweak it, this is Ubuntu's setting.
Re:Isn't this a dupe? (Score:5, Informative)
But the key to remember is that mmap_min_addr implementation is not the bug that allows elevation of privilege. In this case it was a very very old bug in the implementation of pipes. Previously Spender and friends have found bugs in performance counters (one which was actually much worse as it didn't fit into the very narrow class which might be mitigated by mmap_min_addr), in network sockets, and other places. These are the bugs which cause this to be a new story. Once he finds the real bugs he applies some of the same basic techniques (plus a whole lot of thought) to create an exploit. If the Linux kernel was bug free we wouldn't need mmap_min_addr. If mmap_min_addr was bug free (over the years Spender has found multiple problems with my work) this class of bugs would be just a bit less devastating.
Everyone in the kernel development community needs to think of invalid pointer bugs as a larger security threat then they currently do. The lesson here, keep your systems patched.
What design choice? (Score:3, Interesting)
Just what design choice was made (wrong) by Intel, and why is it a bad choice?
Re:What design choice? (Score:5, Informative)
Intel i686 processors had a pretty big performance hit if you used functionality since there was a TLB flush on every kernel trap. I don't believe many kernels made use of it. The PaX security patch set could and Red Hat's 4g/4g split kernels did (RH called them hugemem kernels, although I don't suggest them to anyone as they had their own issues.) The AMD Opteron processors actually had tagged TLBs so they didn't have to flush and performance didn't suffer nearly as badly.
In any case, with x86_64 that ability is simply gone. SPARC is often named as an architecture which doesn't suffer from this specific class of bugs since it always had completely separate kernel space and userspace virtual memory. I heard rumour their might be a brilliant solution that will hopefully come from the PaX/grsecurity team, but I don't believe anything has materialized just yet.
Re:What design choice? (Score:5, Informative)
mmap(0,
char *p = NULL;
*p = 'a';
address 0 now contains the letter 'a' and the program does not fault.
The idea is that if you do the mmap in userspace, fill that area with specially crafted information, then cause the kernel to hit a bug in the software (in this case a pipe) which dereferences a NULL pointer, you can make it operate on data you control. This is due to the fact that userspace and kernel operate in the same virtual address space. Sometimes (often?) this means you can take over the box.
mmap_min_addr tries to address this problem by disallowing a program from mapping the low virtual address space. That means it ONLY affects the class of bugs that involve a NULL pointer. If it's a corrupt pointer instead a NULL pointer mmap_min_addr is totally useless. For either class of bugs hardware segmentation could help. It wouldn't be a security panacea, but it would eliminate the need for the specific hacks which both Linux and BSD use.
Same Exploit from July? (Score:2, Redundant)
The bug was found by Brad Spengler last month.
I thought we discussed this in July [slashdot.org]? Or is this a different exploit?
I think it's pretty clear that De Raadt and others have been discussing this vulnerability for quite sometime. On a list of affected systems [securityfocus.com], you can see it's been known on that site since August. Here's another fix discussed [kernel.org] that involves setting PER_CLEAR_ON_SETID mask to MMAP_PAGE_ZERO and that's from July (unfortunately, as the Register article said, that might cause problems with applications). In fact I think Spengler has bee
Re: (Score:2, Informative)
So it's really a bad design on Intel chips, that all operating system have to work around, except Windows which requires it to work like this... ...and on most Linux and BSD systems it will not work even if unpatched ... and it has already been patched ... and you need to be able to get a user on the local machine to run an app to exploit it (most users install from the Package Manager and so will never run a random downloaded app), and this does not appear to be a remote exploit?
Re:Same Exploit from July? (Score:5, Interesting)
What do you mean Windows requires it to work like this? On Windows accessing a NULL pointer is always an exception, no process is ever allowed to map the bottom page of memory. This has been true since Windows has existed. So in fact it is only Windows systems that are immune to this class of exploit because writing programs and kernel code vulnerable to it leads to an immediate crash.
If you wanted to specify this invariant on Linux you could, you'd just break some existing apps that depend on it. Ironically, it seems that Wine depends on this behavior.
Re: (Score:3, Insightful)
Well, there's always MITRE Common Vulnerabilities and Exposures [mitre.org], which is a good pretty much dupe-free index of reported vulns. Most professional discussions of vulnerabilities tend to use CVE references.
For instance, this particular vuln looks like CVE 2009-2695 [mitre.org]. The one discussed in the July /. article appears to be CVE 2009-1897 [mitre.org].
The CVE pages are pretty good, complete with cross references to discussions and some pretty detailed analysis of the vulnerability.
Re: (Score:2)
Thanks. With the CVE numbers, at least we know what we're talking about.
Re: (Score:2)
Re: (Score:2)
Naah, CVE 2009-3547 traces on the RH Bugzilla as Bug 530490 [redhat.com], "kernel: fs: pipe.c null pointer dereference". Nothing in there about mmapping to page 0. (Pipe filesystem pointer dereferences?)
OTOH, CVE 2009-2695 also googles to a RH bugzilla page, Bug 517830 [redhat.com], " kernel: SELinux and mmap_min_addr". The description on that page sounds suspiciously like the subject of current discussion. This page also has RH patches, in this case in two different RH Security Advisory links.
There appear to be another bugzilla pag
Re: (Score:3, Informative)
The problem we are discussing today is CVE-2009-3547. The root cause of the vulnerability is a null pointer dereference in pipe.c. The proper fix is to patch the kernel. It just so happens that if vm.mmap_min_addr != 0 then the bug cannot be exploited to gain root access. Therefore, mmap_min_addr can be used as a stopgap measure until you are able to patch the kernel. It also happens to be a good idea to leave mmap_min_addr set to a non-zero value to guard against other null-pointer dereference bugs th
Patch (Score:5, Informative)
Re:Patch (Score:5, Informative)
You can either do
# sysctl -w vm.mmap_min_addr = 65536
and redo that every reboot or do
# echo "vm.mmap_min_addr = 65536" >
#
and be done with it.
Re: (Score:2)
No, it's not obvious at all. Which is why a bunch of people are posting instructions on how to do it. Actually, did either of the posts you were replying to use the term "obvious" or "user error"? I sure didn't see it.
I saw people posting relatively clear instructions to protect yourself until a proper fix is released.
I see the same thing on a lot of bugs, be they Windows or Linux or Mac or iOS or whatever. Someone comes up with a way to mitigate the risk and publishes that method to reduce the number o
Re: (Score:2, Funny)
That fix is kind of a pain because you have to reboot Linux. I've found a much more logical fix here [microsoft.com].
Re:Patch (Score:4, Funny)
Re: (Score:3, Funny)
That fix is kind of a pain because you have to use OS X. I've found a much more logical fix here [sun.com]
sysctl vm.mmap_min_addr (Score:4, Informative)
'Most deployed versions of linux'?.
So far only some unpatched RHEL versions allow this local exploit, even the Centos rip-off doesn't have it.
Re: (Score:3, Funny)
But I use RedHat you insensitive clod!
Re: (Score:2)
Re: (Score:2)
This is still a serious problem though!
Re: (Score:2)
Anyway, you can fix it with 'systcl -w'.
Re: (Score:3, Informative)
That's weird, because 9.04 gives: vm.mmap_min_addr = 65536 and so did the 9.10 desktop version a few posts up.
You probably don't have Wine installed. AFAIR Wine needs it set to zero to run some old 16-bit applications, so installing Wine installs a config file which sets it to zero.
Re: (Score:2)
Must be an Ubuntu oddity for Wine, then. My Fedora 11 system gives me:
Re: (Score:2)
Must be an Ubuntu oddity for Wine, then.
Yeah, I don't know of any other distribution than Ubuntu which automatically reconfigures it when you install Wine.
standard author/exploiter response? (Score:5, Insightful)
I'm not a real security guy, but my experiences with security bug reporting shows that nearly all such subtle bugs are pooh-poohed by the original authors till the exploit writer resorts to petulant scaremongering. I'm not sure which one is to blame for either one's behaviour.
All of these attacks IIRC require you to be able to mmap() page zero. Which is why mmap_min_addr is almost never set low enough in a decently protected OS. But the fact is that the exploit is a valid bug for a system which hasn't got that set to 4k. And there is a valid root exploit using pulseaudio (*ouch*) as a vector.
Linus might have been right in saying setuid is a 'vulnerability', but to call it a design flaw is wrong. Setuid is not a design flaw, it is a trade-off - needed for something as simple as 'ping' to function (yeah, ping's got setuid, check it).
Being able to exploit a setuid binary after mmap'ing page zero with executable shell code, via a phpbb vulnerability which is exposed because of lack of php filtering is like saying ... "look, having arranged these six dominoes, I only need to push *one* over".
I'm not denying either of them aren't right in their own way - but invariably original author vs security researcher sets up a very immature exchange of insults (and the ego of both types don't help either).
Re: (Score:2)
While I'm dreaming I'll also take sandboxing for user-executed processes. And a pony.
Re: (Score:3, Interesting)
Setuid is certainly a trade-off, but it seems a little absurd that you need full root permissions to access just the special resources "ping" needs to function. If anything, vulnerabilities like these are calls for a more fine-grained capability-based security system, that only grants the expected privileges needed for a given process to function.
You are aware that in order for ping to work at all, it needs raw sockets so that it can write ICMP packets? Those are restricted because they allow you to spoof all sorts of network traffic (e.g., the ethernet address to IP address mapping) Which Would Be Bad.
The only way to remove the setuid requirement from ping (apart from making your system thoroughly insecure) is to allow messages to be sent and received on raw sockets opened by non-root only if they're ICMP ECHO messages (I'm not aware of any other I
Re: (Score:2, Insightful)
You are aware that in order for ping to work at all, it needs raw sockets so that it can write ICMP packets? Those are restricted because they allow you to spoof all sorts of network traffic (e.g., the ethernet address to IP address mapping) Which Would Be Bad.
This seems less bad than kludgy workarounds.
Network services should never trust that the packets sent to it are not forged. Ever. Session-based authentication If the network services were written with this caveat in mind (which can never really be eliminated anyways, since there's no way of knowing whether the client app is mangling packets) then there would be no problem letting userland programs have access to raw sockets.
Re:standard author/exploiter response? (Score:4, Insightful)
The only way to remove the setuid requirement from ping (apart from making your system thoroughly insecure) is to allow messages to be sent and received on raw sockets opened by non-root only if they're ICMP ECHO messages (I'm not aware of any other ICMP messages that it's useful for user code to send).
That's absolutely not the only way. You can make raw sockets accessible via a node in /dev, which you can assign to a group, control membership in, and setuid/setgid a NON-root user to "ping".
A *lot* of system resources are controlled in this manner (dri, sound, disks). I still don't think it's a sufficiently versatile security model (cf my comment on sandboxing), but it's a good place to start.
Re: (Score:2)
It could be threatening to the network (which should not trust individual nodes much anyway, but many do), but not to the system itself... At least, I don't see how...
How? Thanks.
Re: (Score:2, Informative)
That is being solved with Filesystem capabilities [lwn.net]. Fedora 11 still has ping as setuid, not sure if Fedora 12 beta already switched it
Re: (Score:3, Informative)
Not necessarily. You can create raw sockets with some limitations without root access on OS X. There's enough control to implement ping, but not enough to forge.
Re: (Score:2)
Re:Somebody fill me in.. (Score:4, Funny)
It's not Linus and Theo, it's Theo and everybody.
And yes, it's dueling egos. Theo is a very good coder, and OpenBSD is an amazing system, but Theo should stop talking to the public. It never helps. (Even when he's right, which he usually is when the discussion involves something technical.)
Re: (Score:2, Insightful)
It never helps. (Even when he's right, which he always is when the discussion involves something technical.)
Fixed.
Re: (Score:2)
It's not dueling egos. For there to be a duel, Linus would actually have to care about Theo and his opinions.
Theo seems to have the idea that if security isn't your priority that you are a waste of resources and shouldn't be alive. He basically bashes anyone who doesn't agree with him on anything.
That's because he's a fucking asshole.
Re: (Score:2)
Re: (Score:3, Informative)
What's the beef between Linus and Theo?
Theo is in charge of a BSD-based kernel that is only concerned with security, while Linus is in charge of a kernel that has to accommodate a much wider audience (like people who want to run Wine), and, of course, since both of them also have largish egos, they've both managed to say some silly things about each other's kernel...
Basically, unless you're already a Linus or Theo fanboy, their 'bickering' is not that important. :)
And? (Score:5, Interesting)
Torvalds:
Am I missing something? Torvald's reply actually sounds pretty reasonable to me here. It might be nice if this exploit could be patched, but it seems a little preposterous to me that you could make that work in a way that doesn't leave an exploit. I'd say you need to be locking down your suid binaries more, not blaming kernel management.
Re:And? (Score:4, Informative)
Torvalds is absolutely correct, the whole issue is idiotic and isn't really an "exploit" because it doesn't result in ANY privilege escalation. (You must be root to run an exploit that gives you, um, root!) However, ego-starved security people get to jump up and down thumping their chests about how they h@x0r3d an extremely common Linux distribution and get their names splashed all over the press. Yeah, and instead of mmapping NULL, you can just 'insmod /my/evil.ko' and get the same effect. Sigh.
Those of us who know anything about security just ignore these "researchers". There are far more important bugs - even far more important security bugs - than a root-to-root non-issue. I'll happily patch my system with the next set of kernel updates, but I don't intend to grab it any sooner. It's more important to me that my system stay up and avoid regressions than fix a root-can-get-root non-exploit.
Bishop bashing bonobos (Score:3, Informative)
Re:Bishop bashing bonobos (Score:5, Funny)
Re: (Score:2)
Re:Bishop bashing bonobos (Score:4, Funny)
Exactly, right before Nymphomaniac Nightingale
Re:Bishop bashing bonobos (Score:5, Funny)
...Orgasmic Orangutan...
Re: (Score:3, Funny)
"masturbating monkeys"
Is that the next Ubuntu release after Lucid Lynx? I can't wait!
Exploit? (Score:2)
Is there some sort of exploit code I can run to check if my system is vulnerable? I tried to find some online, but I only came up with some code for SCO Unix [packetstormsecurity.org] and some code [grsecurity.net] that is so horrendously long that I don't dare running it for fear it might do something I don't want to happen on my system.
What's the deal with the masturbating monkeys? (Score:5, Funny)
I read Theo's comments and he's going on an on about Torvald's fixation with masturbating monkeys. Then some member of the openBSD crowd even offers a link to purchasing "your very own" **masturbating monkey** http://www.wellcoolstuff.com/Merchant2/graphics/00000001/20-Apr-07-05.jpg [wellcoolstuff.com]
Then I read Torvald's comment about the Linux exploit, with Torvald referring to the openBSD developers as being __like__ a "bunch of masturbating monkeys".
Ok, so is this like some kind of secret code used among OS kernel developers? Like saying "my shoe is blue but the cow is hungry" really means "Oh man, this code is leaking memory and crashing my system"? Or is this some kind of secret initiation thing, where in order to truly become a member of the OS development club, you have to first ... masturbate a monkey??!! Can somebody explain it, or maybe do some investigative reporting on this?
Nothing more than a publicity stunt? (Score:2)
SUID root yields root... but, wait... (Score:3, Informative)
Linus's comment:
"That does not look like a kernel problem to me at all. He's running a setuid program that allows the user to specify its own modules. And then you people are surprised he gets local root?"
Sounds reasonable to me.
Well, here's the thing... For the exploit to work you need either mmap_min_addr to be 0, or you need your process to have CAP_SYS_RAWIO. In other words, if you were running on a system that had mmap_min_addr set to 0, you could run this exploit without already having root authority. Wine needs this, apparently...
The workaround for mmap_min_addr (by exploiting dangerous SUID code in Pulse) was just icing on the cake.
Kernel default? (Score:2)
Just checked my installations (Debian with custom kernel from kernel.org). They are all at 4096 for mmap_min_addr (and hence not vulnerable), but I seem to be unable to find a place where this is set. Does anybody know whether this is the kernel default?
Re: (Score:2)
It's 4096 (by default) in the Debian-packaged kernel on my system as well.
Local access has never been secure. (Score:2)
I've felt for a long time that giving someone local shell access to a machine is never going to be completely secure. There's just too many degrees of freedom available, and too many different things that need to be secured. This is just another proof of concept of that principle.
With all the various different interfaces we have today, shell access is something only a small percentage of people need. Even those you could likely limit down to a few administrators, some programmers, and possibly a few spec
Re: (Score:2)
``I've felt for a long time that giving someone local shell access to a machine is never going to be completely secure.''
Indeed, it is not. There are various nasty things a regular user with shell access can do.
``This is just another proof of concept of that principle.''
No. This is a vulnerability that makes things worse than they should be. There are various ways to limit what regular users can do. A vulnerability that allows these users to become root means the system is broken, so that users actually get
Theo de Raadt is my hero (Score:2)
I'm glad I don't work with Theo de Raadt. He's a tremendous douche when he's right, and a tremendous douche when he's wrong.
obvious troll is obvious. (Score:2, Insightful)
So, anti-Windows people? Whatcha say now? ;-)
Thank god that independent forces are out there finding and reporting kernel bugs in Linux. If only the bug-finders for windows were so altruistic.
Re:obvious troll is obvious. (Score:4, Insightful)
You misunderstand then. It's not the point that it could never happen, but that it gets found and fixed. This bug was found in the absence of proof of concept code unlike the reverse situation.
Re: (Score:2)
You are trolling since you're trying to imply that this is the first time a flaw was found in the Linux kernel. This has happened numerous times, and it has been posted on /. numerous times, and there's always some fucking troll saying "If this was Windows...". Who the fuck cares!? Why make everything into some political bullshit with extremists throwing rocks at eachother?
I'm going to drop a bomb here and it might shock you all, but it's the truth, here it goes: Linux is not perfect nor did anybody
Re: (Score:2)
Re: (Score:2, Flamebait)
Actually, I was not trolling. Put simply, if this EXACT BUG was discovered in Windows, OS persons would be jumping about like grass-hoppers that THIS could never happen in OS software.
As pointed out elsewhere on these threads, most Linux versions already prevent this bug through a kernel memory map setting. However, WINE, which needs to run things in a Windows-compatible way, doesn't work with that setting, so it's turned off, and people with WINE installed remain vulnerable.
So in a way, this *is* a bug with Windows.
Re: (Score:2)
Why am I a troll? Why is my comment Flaimbait? [sic]
Want to get out of a hole? First, you have to stop digging.
Re: (Score:3, Funny)
Hah, this just shows how EFFICIENT Linux is. Until recently, Windows achieved their local privilege escalation vulnerability rollout by having almost every home user running as fully privileged administrator accounts all the time. Linux achieves all this through a small tweak to the kernel build system, thus getting this feature to 100% of Linux users without any manual intervention at all.
I'd rather pay $400 for bugs likes this (Score:3, Insightful)
And know the fix would be back-ported to Server 2003. How many "stable" kernel versions will the fix be back ported to? Will my 2.4.x kernels get a patch?
Re: (Score:3, Insightful)
``Will my 2.4.x kernels get a patch?''
Are they vulnerable?
Re:I'd rather pay $400 for bugs likes this (Score:5, Insightful)
Lets compare apples to apples. Lets say you have an out-of-maintenance version of Linux (which would be some of the intermediate releases not in use by major distros) and your distro won't be patching you. You have the option of paying someone a lot less than $400 to back-port this patch to your kernel version or doing it yourself.
Now lets say you have an unsupported version of Windows (like NT 3.51) and you find out there's a major security hole in Vista dating right back to 3.51. How are you going to get that fixed? If you answer "by upgrading" then use the same answer with Linux.
The whole point of FOSS is that you're never stuck, you can always just do it yourself or pay someone to do it for you, the vendor can't lock you out of the code running on your systems.
Of course, if you run a maintained version of any Enterprise Linux I'd put good bets down that they'll be patched shortly. If you spun your own distro, then you made the choice to maintain it yourself anyway.
Re: (Score:3, Insightful)
Yup, randomly, anonymously taking your anger out on uninvolved bystanders is definitely the way to correct the system.
I guess it never occurred to you that you are doing the same thing that put you in your little temper tantrum to begin with.
Let's hope the people you target are more mature than you.
Re: (Score:3, Informative)
But the bug is not exploitable on ubuntu, because they set vm.mmap_min_addr > 0 by default.
Ubuntu not necessarily safe (Score:3, Informative)
But the bug is not exploitable on ubuntu, because they set vm.mmap_min_addr > 0 by default.
That doesn't seem to be generally true.
Ubuntu Hardy 8.04 LTS, 2.6.24-25-generic: vm.mmap_min_addr = 65536; Ubuntu Jaunty 9.04, 2.6.28-16-generic: vm.mmap_min_addr = 0. So, by the above logic, Ubuntu Jaunty is vulnerable, although Hardy is safe.
Also seems like vm.mmap_min_addr = 0 for all the Debian boxes I can get my hands on...
(All my comments above relate to the stock/packaged kernels for the distribution)
Re: (Score:2)
It was certainly 0 for Deb. lenny.
Re: (Score:3, Informative)
Re: (Score:2)
Installing the wine package on ubuntu automatically sets mmap_min_addr to 0. The default install will have it set higher
Interesting. (See /etc/sysctl.d/wine.sysctl.conf for some comments).
Solution, remove wine.
Hardly a solution if one needs to use Wine, though, is it? Probably just a good idea to wait for a patched kernel, I should think.
Re:Ubuntu not necessarily safe (Score:5, Informative)
Here's a fun tag line, "Windows applications can even make Linux less secure!"
Re: (Score:2)
One of my (Jaunty) servers has > 0, and my Hardy desktop, which has Wine /and/ Crossover Pro installed, also has > 0.
So I'm not sure about wine always being an issue here (unless my wine install won't work for certain apps... I wonder)
Re: (Score:2)
Also seems like vm.mmap_min_addr = 0 for all the Debian boxes I can get my hands on...
I just looked and it's >0 on my Debian box, which is patched regularly but still uses packaged kernels. So I guess that would be one of the ones you can't get your hands on. :P
Re: (Score:2)
Perhaps it's Wine, then, or another package that has modified it: see http://linux.slashdot.org/comments.pl?sid=1430160&cid=29978100 [slashdot.org] and further comments.
Re: (Score:2)
# sysctl -n vm.mmap_min_addr
0
On 9.10. Right. Did you try running the command yourself?
Full quote from article (Score:3, Informative)
The null pointer dereference flaw was only fixed in the upcoming 2.6.32 release candidate of the Linux kernel, making virtually all production versions in use at the moment vulnerable.
You know you can click on the article links and actually read them.
Re: (Score:2)
Re: (Score:2)
The bug is fixed in the RC, but it's not exploitable in older kernels except when vm.mmap_min_addr = 0. I'm running the vanilla 2.6.30.3 kernel on Gentoo and it's not vulnerable, so it seems likely that you're only vulnerable if your distro (or you, if building a custom kernel) decided to change the default value.
Re: (Score:2)
Interesting, on karmic, I have:
Then again, I don't know if my system is actually vulnerable, because I have yet to see a description of how the exploit works.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Ahhh, man. Someone mod him up "+1 originality" or "+1 Funny Troll" or something. I'm sitting in front of my StraightBuntu machine laughing my ass off. ;^)