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)."
Good point, article title now changed.
s!
Ignore the "p2p is theft" trolls, they're just uninformed
its been in the kernel since the 2.2 days .. the 2.2 series kernel's are also affected.
read the synopsis: here"Proof-of-concept exploit code has been created and successfully tested giving UID 0 shell on vulnerable systems."
Just because the proof of concept exploit was created DOESN'T MEAN IT WAS RELEASED! If Linus and one other guy are the only ones with the proof of concept exploit, there is no reason to fear the script kiddies yet.
They did NOT say if the reason for the fix was because someone released an exploit, or if the reason for the exploit is simply to prove the vulnerability works, and was not publically disseminated.
Go STFU.
The bug has also been confirmed in 2.6.0-rc1. For those that have made the jump, a patch was just posted to the linux-kernel mailing list. I'm guessing -rc2 will follow soon.
Crud, that should have been 2.6.1-rc1 of course.
Since you meant 2.6.1-rc1, I assume that it applies to 2.6.0?
STOP MISUSING APOSTROPHES, YOU MORONS!!!
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
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.
RedHat Network has patches for RH 7.3. From the RHN Errata page : "We have provided kernel updates for Red Hat Linux 7.1-8.0 with this advisory as these were prepared by us prior to December 31 2003. Please note that Red Hat Linux 7.1, 7.2, 7.3, and 8.0 have reached their end of life for errata support and no further errata will be issued for those distributions."
"Special weapons and training" yields 42 google hits, while "special weapons and tactics" yields 17,000.
I'd say you've got the accepted definition.
There are no trails. There are no trees out here.
Okay:
Hope that helps!
demi
Modules (or really any third-party code regardless of method be it /dev/kmem or modules or whatever) having access to the syscall table of a running kernel is (1) evil, (2) nonportable - it won't work on many of our architectures, and (3) likely to become even harder as the kernel gurus try to defeat people doing stupid things like this.
BTW, this also affects things like (why would you need this?) realtime virus scanners that hook syscalls. Please, don't do this. If the argument is that you need the machine to stay up because it's too important to reboot for a patch, then you definitely should not be inserting modules that *intentionally overwrite important chunks of kernel memory* because if there's the slightest thing wrong, your machine will either crash or begin to do bizarre things. You could end up with data corruption and/or loss for an extended period before you even realize it. Do not do this. It is not what you want. Believe me.