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 ?
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).
Ignore the "p2p is theft" trolls, they're just uninformed
Use Depenguinator on all the unpatched boxen! Let the revolution begin! >:)
Yup, another 5 minutes down the drain.
AAAAAARGH!
It's XFS. NOT XFS Filesystem. I'm gonna do something illegal to the next person that says ATM machine, too.
For the Microsoft trolls to pick this one up.
Is this just more proof that Linux was built by amateurs? Or wait - I know - that Linux can't be trusted because the source code is open.
Now, for those who think I'm serious, think about it for a moment. Slashdot hypes up every single MS vulnerability as "proof" that MS systems are inherently insecure. And I wouldn't disagree that MS systems are insecure. But discovering a single (or a few) vulnerability doesn't make an OS insecure.
What it comes down to is vigilance and design. The numerous security holes in MS products are a result of bad design, not merely a mistake or two. And this is the big difference between this vulnerability - a mere isolated mistake - and Microsoft's complete lack of engineering which ensures that their software _will_ have security holes.
Okay, flame away Microsofties!
The society for a thought-free internet welcomes you.
unsubscribe linux-kernel
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
Uh, right. "make bzImage" actually takes a couple minutes on any decently fast computer. You don't need to rebuild all the modules, and even that will take much less than an hour unless you're running ancient hardware.
LOAD "SIG",8,1
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
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."
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
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.
Software is written by humans, and humans make errors, so software has bugs.
All software.
The sysadmin motto (abridged) is 'all software sucks, all hardware sucks'
I just looked through the bugtraq archives, and found 3 local root exploits for OpenBSD in the year 2003. That's the same class of problem as was found in Linux.
Security is a mindset, and a practice. It's not a platform.
Zapman
$ man nice
On kernel 2.4 and earlier, you usually gave the X-server a negative nice-value to give it higher priority which lead to somewhat better responsivness. But the 2.6-kernel has a new rewritten scheduler (?) that detects if the process is interactive or not and handle them differently to make interactive apps more responsive while giving non-interactive apps more throughput. By renicing the X-server you foul the kernel to not make use of this and thus get a much less responsive X desktop.
If you just compiled and installed the 2.6 kernel on a 2.4 distro that is not 2.6-ready you'll have to mock with the X startup-scripts to remove the nice/renice-stuff to make use of the great 2.6 desktop-features.
My other account has a 3-digit UID.
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.