Slashdot Mirror
Linux 2.4.24 Release Fixes Root Vulnerability
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)."
Was this bug introduced in 2.4.23 or has it been in the 2.4 series all along ?
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).
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
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.
It's sgi's eXtended File System.
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.
/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.
:0 Or if it fits, it will be disasterous.
: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.
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
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.
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.