An important Linux fix
It's not often that Linux needs to be fixed, but a recently discovered security problem does deserve your attention.
View full article »
Esther Schindler
If the comments are ugly, the code is ugly
claird
SVG a graphics format for 21st century
pasmith
Take Chrome OS for a test spin
Sandra Henry-Stocker
Solaris Tip: Have Your Files Changed Since Installation?
jfruh
Android fragments vs. the iPhone monolith
mikelgan
What Gizmodo missed about the Pro WX Wireless USB disk drive
Sidekick: The Good News & the Bad News
Either way you look at it Microsoft Data Center management did not follow standards or best practices in this failure. In which case it makes me wonder more about the outsourcing of corporate data much less personal data.
- mburton325
Join the conversation here
Quick, practical advice for IT pros. Made fresh daily.
Want to cash in on your IT savvy? Send your tip to tips@itworld.com. If we post it, we'll send you a $25 Amazon e-gift card.
Karmic
Checking in Karmic Koala, mine is in fact 0!! Although I do have Wine installed, but I shall be keeping my eye on updates, and having a look at those permanent fixes.Karmic with wine = 0 for me as well.
I followed the instructions and got the bad news also. I too will wait (and hopefully not long) for the patched kernel. I was thinking about getting rid of WINE and well, I decided that's no solution for my needs.Karmic (no-wine) OK :)
Checked and I'm fine - Thanks for a way to confirm.Particular applications with wine need the 0 address accesable.
Note Particular applications. About 90 percent of time you can disable it with no ill effect.Just moving it to 1 from 0 blocks the issue and lets all bar a few badly coded programs work.
As with all these things details get lost.
Simple thing to follow.
1) Disable it.
2) If applications don't work try value of 1.
3) If 0 is need really consider if you need that application.
No reboot?
"(...)like most Linux users, I tend to re-boot my systems once every blue moon, (...)"Is that so? Do you leave your car with the engine idling away in the garage in the evening because you're going to need it in the morning again?
I switch my work computer off when I go home and switch my home computer off when I don't need it anymore. Why waste electricity on a system I don't need presently?
What I'd like to know: does that security risk apply only to non-privileged users with physical access to the computer or does it apply to users over the network, too, on a system which doesn't accept logins from outside anyway? Is it necessary for a user to have an account on the system in the first place in order to use this exploit? Because that would mean that most people who aren't running servers don't have a problem anyway.
Fedora ok
Just tried the test on Fedora 11 and 9. Both return non zero values.Debian 5.x is 0
Debian 5.0.x has a value of 0 without wine installed. Debian 6 is 4096.to fix Deb 5.x create a file /etc/sysctl.d/mmap_min_addr.conf with the following content
# Prevent kernel null pointer vulnerability
vm.mmap_min_addr=1024
OpenSuSE 11.1 ok
Just run a full update on my 11.1 32bit OpenSuSE with the vendor patches, and the number is 65536openSuSE vulnerable?
I'm running openSuSE and I didn't change the setting manually, but on my machine the minimum pointer address is 65535, so it's not vulnerable.SuSE fixed in August
Novell Security AdvisoryContrary to what is reported in the article, this was fixed in August 2009. See the link, love the SuSE :)
Excerpts:
Date: Thu, 20 Aug 2009 16:02:11 +0200
---- snip ----
The mmap_min_addr sysctl is now enabled by default to protect
against kernel NULL page exploits.
[SLE11, openSUSE 11.0-11.1]
The -fno-delete-null-pointer-checks compiler option is now used to
build the kernel to avoid gcc optimizing away NULL pointer checks.
Also -fwrapv is now used everywhere.
[SLES9, SLES10-SP2, SLE11, openSUSE]
this has already been
this has already been backported by most of the key vendors: i.e. redhat and debian, so most users are protected at this pointCentOS is fixed
Just checked my CentOS servers running 5.3 and 5.4, and it's fixed on them. Both releases show 4096. It's probably safe to say the upstream RHEL releases of 5.x are fixed as wwell.Karmic
Most seem to be using Karmic.... Ubuntu's is the best hope for linuxThis is already fixed
On kernels 6.31-rc3 onwards. And sure most of distros had backported it.And the mmap_min > 0 trick didn't solve anything. Just make it non trivial. So don't feel safe just for this, exploiters will know already the workarounds.
Go here for more info:
http://blog.cr0.org/2009/06/bypassing-linux-null-pointer.html
You need a patched kernel or a kernel above 2.6.31-rc3
Karmic has it back to 0 to avoid dosemu and wine problems. (The mmap trick breaks it)
This article scares everyone and points to a wrong solution that adds even more confusion. More investigation next time, please.
1 after 65535
Or, you can use any other numeric value up to 65535So, why can't the value be more than 65535?
My Hardy, with full updates, has a value of 65536.