An important Linux fix

It's not often that Linux needs to be fixed, but a recently discovered security problem does deserve your attention.

By sjvn  15 comments

Most of the time you can go for months, years, without patching your Linux distribution and not be in any real danger. A recently uncovered security hole in the Linux kernel does deserve your attention.

Specifically, Earl Chew, a Linux developer, and, at about the same time, Brad Spengler, creator of the Linux security program Grsecurity, discovered that there was a possible null pointer error that could, in theory, enable non-root users grab administrator privileges. You don't want that to happen.

This particular bug, known in developer circles as CVE-2009-3547, hits all modern versions of the Linux 2.6 kernel It's been fixed in the upcoming 2.6.32 RC (release candidate), but unless you're running on Linux's bleeding edge, you're not running that version of the kernel.

So chances are you might have this problem. I say might because for this security hole to be open the value to the mmap_min_addr pointer has to be zero. If it's not, you're safe.

Most distributions give this pointer a value. But, there are claims that to enable Wine, the popular program that lets you run Windows programs on Linux, its value must be set to zero. That's not true though. On my own Linux systems, I often run Wine, and its commercial big brother, CrossOver Linux, and on my PCs, mmap_min_addr is not set to zero.

That aside, there are some Linux distributions, such as Red Hat Enterprise Linux and Novell's SUSE Linux where the pointer is set by default to zero, which makes them vulnerable to attack. In Red Hat's case, the fix is already available. With SUSE, the permanent patch, as of November 6th, is still on its way.

That doesn't mean, however, you have to sit and wait for your upstream provider to come up with a fix. You can reset the pointer yourself while holding out for the permanent fix.

To see if you need to bother, head over to a shell and run the following command:

cat /proc/sys/vm/mmap_min_addr

If this gives you a zero or no value, then you're potentially vulnerable. If it gives you any other number, life is good and you don't need to worry with it.

But, if the news is bad, just run this command:

sysctl -w vm.mmap_min_addr="1024"

Or, you can use any other numeric value up to 65535 and your system will be safe until it's rebooted again.

There are ways to permanently set it to a new value, but since, like most Linux users, I tend to re-boot my systems once every blue moon, I'm not going to bother with these.

The way I figure it, all the Linux vendors will have this hole patched long, long before I reboot my systems again. Your usage may vary.

In any case, if you're running Red Hat, patch now. If you're running a Red Hat variant, like CentOS or Oracle Unbreakable Linux or a SUSE Linux, you'll want to run the sysctl fix. Debian and Ubuntu users seem to be safe, but if you want to make doubly sure, just run the cat command and you'll know for sure.

15 comments

    Anonymous 2 years ago
    Hello,On OpenSuSE 11.2 setting mmap to 0 wasn't enough. I had to disable apparmor, putting arrarmor=0 on the kernel launch command (in GRUB).
    Anonymous 2 years ago
    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.
    Anonymous 2 years ago
    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.htmlYou need a patched kernel or a kernel above 2.6.31-rc3Karmic 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.
    Anonymous 2 years ago
    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.
    Anonymous 2 years ago
    Most seem to be using Karmic.... Ubuntu's is the best hope for linux
    Anonymous 2 years ago
    this has already been backported by most of the key vendors: i.e. redhat and debian, so most users are protected at this point
    Anonymous 2 years ago
    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]
    Anonymous 2 years ago
    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.
    Anonymous 2 years ago
    Just run a full update on my 11.1 32bit OpenSuSE with the vendor patches, and the number is 65536
    Anonymous 2 years ago
    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 vulnerabilityvm.mmap_min_addr=1024
    Anonymous 2 years ago
    Just tried the test on Fedora 11 and 9. Both return non zero values.
    Anonymous 2 years ago
    "(...)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.
    Anonymous 2 years ago
    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.
    Anonymous 2 years ago
    Checked and I'm fine - Thanks for a way to confirm.
    Anonymous 2 years ago
    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.

      Add a comment

      Post a comment using one of these accounts
      Or join now
      At least 6 characters

      Note: Comment will appear soon after you have activated your account.
      Obscene/spam comments will be removed and accounts suspended.
      The information you submit is subject to our Privacy Policy and Terms of Service.

      ITworld LIVE

      SecurityWhite Papers & Webcasts

      White Paper

      A Proactive Approach to Server Security

      Learn why security-conscious organizations are taking a more proactive approach to server security. Download this Spire Research whitepaper to understand how you can eliminate the threat caused by today's more advanced threats and protect your organization's most valuable data.

      White Paper

      Protection Against Modern Cybersecurity Threats

      Download this case study to learn how this accounting and consulting giant uses Bit9's adaptive application whitelisting to offer employees flexibility without jeopardizing enterprise safety.

      White Paper

      Stop Hackers Before They Attack

      Hacktivism, Identify Theft, Financial Gain, Cyber War - regardless of motivation, stopping today's hackers requires a new proactive approach to protecting endpoints. Learn how this New England hospital, breached multiple times by targeted attacks, put an end to the malware with Bit9 Parity. Their IT team can now identify malware and secure PCs and workstations -protecting patient care and privacy.

      White Paper

      From the Frontline - Preventing APT

      Is your company's network secure? Are your endpoints and servers secured? Before you answer, read this case study on a US Military Command that discovered no matter how much you educate users, hackers can get through traditional defenses. This targeted attack blew through all layers of their security, except one: Bit9 Parity's advanced threat protection.

      White Paper

      Protecting Point of Sale Systems from Targeted Attack

      If you are responsible for protecting retail systems, download this case study to learn how this retailer eliminated the threat of malware on their POS systems using Bit9's award winning solutions.

      See more White Papers | Webcasts

      Ask a question

      Ask a Question