Slashdot Mirror

← Back to Stories (view on slashdot.org)

Linux 2.4.24 Release Fixes Root Vulnerability

Posted by simoniker on from the version-plus-plus dept.

diegocgteleline.es writes "Linux Kernel 2.4.24 has been released and is available on kernel.org. It seems there's a bug in the mremap(2) system call, where a local user can get root privileges.The new version has been released only with the most important bugs fixed - the rest of the changes have been postponed (those changes include the XFS filesystem)."

14 of 436 comments (clear)

  1. Article title misleading... by kevin_conaway · · Score: 4, Interesting

    Was this bug introduced in 2.4.23 or has it been in the 2.4 series all along ?

  2. Anyone written an exploit yet? by cyt0plas · · Score: 3, Interesting

    Was this one of the usual "inform, wait, release" cases, or is this one of those "oh crap! time for a fix!" cases.

    In other words, should I, Joe Schmoe SysAdmin be afraid of the script kiddies yet?

    --
    Contact Me (got tired of viruses emailing me).
    1. Re:Anyone written an exploit yet? by Xzzy · · Score: 4, Interesting

      > should I, Joe Schmoe SysAdmin be afraid of the script kiddies yet?

      As soon as an exploit is publicised, yes you should.

      Since it's a local exploit it's not as bad as it could be, but I guarantee you if a rootkit didn't already exist, once is being worked on now.

      If you trust all your open services to not execute foreign code you can probably doze a bit, but that's walking on a razor's edge.

  3. Well... by Film11 · · Score: 2, Interesting

    This doesn't apply to me since I don't have Linux...yet. I plan to get a Knoppix cd, after all, it was on a PCFormat that came a while ago, if only I could find it. Although I know nothing about Linux, so some links to some beginner sites could be useful =\.
    Also, is Linux more secure than Windows, because I hear a fair amount of Linux security holes more than Windows, or maybe I'm just not perceptive enough.

    --
    ):
    1. Re:Well... by wasabii · · Score: 3, Interesting

      A remote exploit woudl be an exploit on a service such as Apache, or directly in the kernel's TCP stack. Something which would allow a user who does not have access to the machine to get it.

      A local exploit would be an exploit somebody sitting at a shell, or at the keyboard of the system itself, could use to elevate prividiledges he already has.

      Imagine this local exploit: A program, that runs as root, creates a temporary file in /tmp, it then reads that file, and processes the information in it. Imagine if you, a hacker, had access to that computer. /tmp is for temporary files, anybody can create files in it. You create the file in /tmp that this other program expects, and the other program reads from it, and has some sort of error (vulnerbility) where you can cause it to do whatever you want. You, a normal user, just hijacked another user's (possibly root's) program. A local exploit. To exploit this, you must have access to /tmp. You must be able to run programs on the system.

      Windows does not deal with local exploits, ever. Imagine all the programs that create files in C:\WinNT\Temp. All the programs that read from registry entries. I would bet the vast majority of these could be exploited without a thought. There are probably thousands/millions of local exploits in windows. But you never see patches for them. Because nobody cares. Windows isn't designed to be "multiuser". They are trying to shove it into that role, and it won't fit. :0 Or if it fits, it will be disasterous.

      Linux on the other hand, commonly has many users. Think of shell accounts where you can telnet/ssh in, and run your programs. How many windows computers can you ssh into?

      As MS tries harder and harder to penetrate this market, the market that Unix has historically stood in, they're going to have to radically alter their development methodologies. They have no idea what sort of task they are up against. :0 It'll be fun to watch. When you develop Unix programs, just CLI or GUI programs, these kind of condititions are always taken into consideration. I've never seen a Windows programmer even consider them.

  4. Argh, just finished 2.4.23 went back from 2.6 by Anonymous Coward · · Score: 2, Interesting

    2.6 seemed pretty good to me, except one thing: I play games like enemy territory and map times just kept getting longer and longer as I played. Only shutting down et and restarting solved it. On 2.4 the maps load at about 20-30 secs, in 2.6 it would start at that and keep getting longer, last map was over 2 minutes until I was disconnected from server.

    I tried 2.6.1rc1 and with the -mm patch. Same thing. So now I'm back with 2.4.3. But in last few versions of the 2.4 series I get extreme slowdowns when using my psx pad on my lpt port. This worked fine in 2.6 and in much older kernels in the 2.4 series.

    I was just looking at the gamecon.c file for 2.6 and comparing to 2.4 and noticed a PSX_DELAY value was different. I modified it to 2.6 value but same thing.

    Anyone knowledgeable on this stuff tell me is it safe to use the gamecon.c from 2.6 for 2.4? Or why I would get these load times issues with 2.6?

    1. Re:Argh, just finished 2.4.23 went back from 2.6 by Anonymous Coward · · Score: 2, Interesting

      run top and make sure it doesn't say -10 or anything other than 0 for X's nice value, if it does say -10 or something you'll need to find what script or config file is setting it and change it to 0 for 2.6

  5. Re:Can't Wait! by Meat+Blaster · · Score: 2, Interesting
    I'm not backing Microsoft, because how much is it worth being comparatively secure to another product (they've got three remote-roots and we've only got two!).

    I'm still convinced that a closed-source competently-designed operating system will be, on the whole, less vulnerable than an open-source competently-designed operating system. The theoretical million eyes on the source isn't worth as much as it (used to be) hyped, because you're not talking about a million security professionals and you're really talking about maybe a thousand eyes on different parts of the code.

    I'm still more comfortable with Linux than Windows, and not just because of security concerns, but I'd be much more convinced of the security benefit if there were more eyes looking proactively for things like this.

  6. Re:Redhat 7.3 updates? by Spoke · · Score: 2, Interesting

    Fedora Legacy isn't quite up and running yet, but RedHat released errata RPMs for RedHat 7.x, 8.0 and 9. If you read the archives of the Fedora Legacy list, you will get a good idea of the state of the project.

  7. But that's not the real problem. by Ungrounded+Lightning · · Score: 3, Interesting

    In Linux... (Score:-1, Troll) you have to spend 4 hours recompiling your kernel for stuff like this.

    In Windows, you just install a small binary patch that takes less than a minute.

    A few months later when/if they get around to releasing the small binary patch. B-)

    But there IS a real problem - at least as of the last version of RedHat I installed. (And I'm presuming the same is true with other "commercial-grade" distros, so somebody PLEASE let me know if there's one where this is NOT true.)

    In Linux the commercial distributions make it easy to do an initial install - once. But the included documentation doesn't tell a newbie how to compile and install a new kernel. Or how to download a kernel patch (unless, MAYBE, if he figures out it might be needed and digs deep and hard for it).

    With Red Hat:

    - The install tools are all directed at getting him from bare (or windows-loaded) machine to login prompt.

    - The phone support included with the distro (before the recent policy changes at least) stops when you get installed to where you have a login prompt.

    - The admin tools are essentially all directed at tuning that initial install. (Exception is rpm - with some of the most convoluted manual pages I've seen in a long time. But even that leaves him in the same position as a Windows user - waiting for an RPM patch.)

    Source included but NO documentation on how to build from source. The nicey-nice admin tools make it worse, by hiding what's going on from the user so he has NO clue what's going on behind the pretty GUIs.

    I'll believe Linux is ready for prime-time when the distro documentation includes:

    - A keystroke-by-keystroke walkthrough of applying a patch.

    - A keystroke-by-keystroke walkthrough of building and installing a distribution-equivalent kernel from source (so the user has a trusted baseline from which to make ONLY the changes he intended).

    - Explanations of the configuration-file twiddling done by the admin tools - broken down by GUI page.

    Anything less leaves him in a position much like a windows user - dependent on the vendor or a consultant. Unable to make his own changes (beyond config-tool knob-twiddling) without a long learning process (much like becoming a MSCE) because any change he makes might shatter his configuration beyond his own ability to recover (short of a reinstall from scratch).

    Yes, with Linux you can learn this stuff without having to go buy a monopoly's school supplies. But at least Microsoft understands that a user has other things to do than become a guru. Linux distro providers and hackers, on the other hand, seem to have forgotten the learning curve they climbed.

    Linux is still in the model-T / hot-rodder stage. Versus, say, Microsoft, which has advanced to black-box engine control / recall and dealer-fix stage. (Except that the recalls are too few and too often not-free. Unlike the "big three" plus foreign compeition, a dissatisfied customer can't dump the latest in a series of lemons and switch to a competitor's functionally-equivalent peach.)

    --
    Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
  8. Can anybody explain... by Avian+visitor · · Score: 2, Interesting

    If the only changes from 2.4.23 to 2.4.24 were some "minor" bug fixes, why do I see such a big difference in the size of the kernel binary?


    -rw-r--r-- 1 root root 667113 Dec 1 22:44 vmlinuz-2.4.23
    -rw-r--r-- 1 root root 713946 Jan 5 18:53 vmlinuz-2.4.24

  9. Kernel patches as modules? by Ktistec+Machine · · Score: 5, Interesting
    Hi folks,

    I remember, back when the last ptrace bug was found, some kind soul created a kernel module that (a) renamed the current ptrace function to something else and (b) implemented a new wrapper function that first checked to see if you were root, before deciding whether to call the old ptrace. Slick!

    I'm surprised this sort of workaround hasn't been done for other kernel bugs. It seems it wouldn't even have to be a workaround. A module could actually provide a new, repaired version of the buggy routine. Couldn't it?

    I can imagine insmoding a list of "kernel-fix" modules at boot time. Then, every once in a while , I'd upgrade my machines to a new kernel, but without the urgency of getting a new kernel installed RIGHT NOW! to fix a small (code-wise) security problem.

  10. Re:XFS Filesystem by TheScienceKid · · Score: 3, Interesting

    It's sgi's eXtended File System.

  11. Apparently Inquirer worse than brain dead monkey by moncyb · · Score: 2, Interesting

    Arrgh! Not more people who just count the number of vulnerabilities! I just skimmed that article, but it looks like crap to me. Standard Microsoft trolling, nothing else.

    Don't listen to anyone who claims something is more secure based on the number of vulnerabilties. I bet if you look at all the "vulnerabilities" counted for Debian, most of them were for crap you'll never use (they seem to have every single little open source project ever made) or something stupid like "users can manipulate the high score file of some lame obsure video game." You have to look at what the vulnerablilites are.

    You should also take into consideration whether or not the organization in charge will disclose all vulnerabilities they know about. Debian is very open, they probably couldn't keep such things a secret if they wanted to. Also, I think Debian has far more packages than any other Linux distro (certainly far more software than MS ever put out), so obviously they are going to discover more problems.

    When I hear someone say a MS product is more secure than anything, my bullshit meter flies off the dial. Maybe something written by a ten year old script-kiddie. ...or something deliberately botched. I buy the statement something made by IBM or HP would be more secure (especially considering those projects are probably more mature), though obviously anything written by that reporter can't be trusted, and merely listing the number of disclosed vulnerabilities doesn't mean anything.

    This is total crap (emphasis mine):

    The other significant feature [talking about the three most "secure"] of these operating systems is the language in which they are written. The two from IBM are both written in assembler...

    C and similar languages that use pass-by-value techniques are exceptionally prone to buffer overflow... Avoiding the use of these languages at the most vulnerable points, namely user I/O and network I/O, would appear to be wise. Linux, Unix and Windows are almost entirely written in C, and most of their middleware and application software is also in these vulnerable languages, so it should come as no surprise that they are less secure than OpenVMS, OS/400 and zOS.

    Does this guy know what assembly language is???? It doesn't have any sort of bounds or type checking at all---well unless it is built into the processor design (I am not familiar with mainframe CPUs), and if it is, a C compiler written for that processor will most certainly use those features too.

    Also, looking at the table, they included OS 9. Does that version even have a filesystem permission system or a concept of users? Why don't they just include Win98 too. That's like saying "the building uses empty frames instead of doors. We didn't find any problems with the locks, therefore the building must be secure."