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)."
I thought that everyone jumped to the 2.6.0 by now?
Oh wait, it's been 2 weeks already,
TIME FOR A RECOMPILE!!
do() || do_not();
Was this bug introduced in 2.4.23 or has it been in the 2.4 series all along ?
Ignore the "p2p is theft" trolls, they're just uninformed
Use Depenguinator on all the unpatched boxen! Let the revolution begin! >:)
AAAAAARGH!
It's XFS. NOT XFS Filesystem. I'm gonna do something illegal to the next person that says ATM machine, too.
unsubscribe linux-kernel
> 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.
Possibly due to the fact that the last kernel fix was a week ago, or just that the patch is minoor, or because RH is being kind to those of us who still have reasons to run RH 7.3 just yet, but look to RH for a kernel update if you need one for 7.x and 8 which are unsupported in 2004. Thanks RedHat. Saved me a panicked kernel decision. I desperately didn't want to return from a vacation to a timetable jump of a few weeks.
I am, and always will be, an idiot. Karma: Coma (mostly effected by
Holes like elevation of privileges (like this one) cannot be used by worms since they work only when you already have access to the system. So while these bugs are bad enough, they are still not nearly as bad as the Win-RPC, or the bugs that allowed Nimda, CodeRed etc. to exist.
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.
All advanced operating systems can be insecure depending on configuration.
However, regarding your specific question, you see more security exploits for Linux probably because Linux has both remote and local exploits; the vast majority are local exploits. A local exploit is usually only a concern in a multiuser mainframe-style environment where you have "trusted" users who can log in to the machine. These users can log in and use a local exploit to elevate their priviliges on the machine. If the user doesn't have a login account, they do not have the opportunity to perform the exploit. Local exploits generally use buffer overflows or hijack split-second temp files to do their nastiness.
Windows generally does not operate in a multiuser fashion, so these exploits are not as pertinent. Having written Windows software for years, I can tell that if local exploits ever become a concern for Windows (e.g. if Windows ever goes multiuser in a big way, where a local user may want to exploit the machine), almost every Windows application will have big problems with local exploits, since they have been built assuming that the local system is single-user and temp files and registry entries are assumed to be safe.
what 'work'?
how long does it take you to prepare a kernel-upgrade?
Mielipiteet omiani - Opinions personal, facts suspect.
Having written Windows software for years, I can tell that if local exploits ever become a concern for Windows (e.g. if Windows ever goes multiuser in a big way, where a local user may want to exploit the machine), almost every Windows application will have big problems with local exploits
...are pretty much only for convienience, that is to keep user settings and such separate among a group of mutually trusted users (like say, a family). There's not much in terms of real security.
That users created at install time default to admins with no passwords only goes to prove that even more. Which is fine, as long as a) noone unauthorized can get to the machine and b) all the users trust eachother.
On the other hand, local exploits are a grave concern in many settings, say for example a university where each student has a local account. So they should by no means be taken lightly, even if they don't produce worms.
Kjella
Live today, because you never know what tomorrow brings
Okay:
Hope that helps!
demi
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.