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: hereThe 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.
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.
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.