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
In this case, "-1, Flamebait" can be read as "The truth hurts, don't it?"
My experience with Linux is the same as the parent poster's: patching, patching, patching if you're up-to-date with the latest 2.x version, or running a kernel from 3 years ago if you prefer stability to tinkering.
This doesn't apply to me since I don't have Linux...yet. I plan to get a Knoppix cd, after all, it was on a PCFormat that came a while ago, if only I could find it. Although I know nothing about Linux, so some links to some beginner sites could be useful =\.
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.
):
I don't expect I'll be switching to 2.6 until May. The 2.6.1 release is very important to me as it includes a lot of patches previously rejected by Linus. I expect by May we'll have 2.6.3 at least and this kernel will be on its way to rock solid stability. As for now, 2.4 is in maintenance mode and will only be updated for bug fixes. This is great because it will replace the 2.2 kernel in this arena. But in this limbo we are in now, 2.4 is good enough for me.
Use Depenguinator on all the unpatched boxen! Let the revolution begin! >:)
#uname -a ...but I guess you are a troll...
patch -p1 < patch-2.4.24
make clean dep
make bzImage modules_install
Depending on your situation, configure your boot loader - grub or lilo - to recognize the new image.
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.
...not only is there a fix already, but I didn't have to badger anyone to get it - it was announced! Off to emerge my new kernel... ;)
libertarianswag.com
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
2.6 seemed pretty good to me, except one thing: I play games like enemy territory and map times just kept getting longer and longer as I played. Only shutting down et and restarting solved it. On 2.4 the maps load at about 20-30 secs, in 2.6 it would start at that and keep getting longer, last map was over 2 minutes until I was disconnected from server.
I tried 2.6.1rc1 and with the -mm patch. Same thing. So now I'm back with 2.4.3. But in last few versions of the 2.4 series I get extreme slowdowns when using my psx pad on my lpt port. This worked fine in 2.6 and in much older kernels in the 2.4 series.
I was just looking at the gamecon.c file for 2.6 and comparing to 2.4 and noticed a PSX_DELAY value was different. I modified it to 2.6 value but same thing.
Anyone knowledgeable on this stuff tell me is it safe to use the gamecon.c from 2.6 for 2.4? Or why I would get these load times issues with 2.6?
Isn't that an oxymoron?
Well, it should be.
The coolest voice ever.
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
Fedora Legacy isn't quite up and running yet, but RedHat released errata RPMs for RedHat 7.x, 8.0 and 9. If you read the archives of the Fedora Legacy list, you will get a good idea of the state of the project.
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
The title of the article says "Root Vulnerability"!
Anybody with any rudimentary knowledge knows that this is about the worst possible thing they could say. They did not even say "Local Root Vulnerability" which they could have.
If the only changes from 2.4.23 to 2.4.24 were some "minor" bug fixes, why do I see such a big difference in the size of the kernel binary?
-rw-r--r-- 1 root root 667113 Dec 1 22:44 vmlinuz-2.4.23
-rw-r--r-- 1 root root 713946 Jan 5 18:53 vmlinuz-2.4.24
cd /usr/src/linux-2.4.23 ; patch -p1 /path/to/patch.diff
Recompile and off you go.
Okay:
Hope that helps!
demi
Damn. < got removed. Sorry.
/path/to/patch.diff
patch -p1 <
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.
Even so, "New Technology" is a name for that technology.
No. "Windows NT" is a trademark. The law recommends using trademarks and service marks as adjectives. Even if the mark consists of initials, one of which would expand to a generic term for the product (such as "FS" in "XFS" or "T" in "NT"), the law still recommends following the mark with a spelled-out the generic term.
It means your kernel is vulnerable. Writing an exploit that yields root privileges is much harder though.
Arrgh! Not more people who just count the number of vulnerabilities! I just skimmed that article, but it looks like crap to me. Standard Microsoft trolling, nothing else.
Don't listen to anyone who claims something is more secure based on the number of vulnerabilties. I bet if you look at all the "vulnerabilities" counted for Debian, most of them were for crap you'll never use (they seem to have every single little open source project ever made) or something stupid like "users can manipulate the high score file of some lame obsure video game." You have to look at what the vulnerablilites are.
You should also take into consideration whether or not the organization in charge will disclose all vulnerabilities they know about. Debian is very open, they probably couldn't keep such things a secret if they wanted to. Also, I think Debian has far more packages than any other Linux distro (certainly far more software than MS ever put out), so obviously they are going to discover more problems.
When I hear someone say a MS product is more secure than anything, my bullshit meter flies off the dial. Maybe something written by a ten year old script-kiddie. ...or something
deliberately botched. I buy the statement something made by IBM or
HP would be more secure (especially considering those projects
are probably more mature), though obviously anything written by
that reporter can't be trusted, and merely listing the number
of disclosed vulnerabilities doesn't mean anything.
This is total crap (emphasis mine):
Does this guy know what assembly language is???? It doesn't have any sort of bounds or type checking at all---well unless it is built into the processor design (I am not familiar with mainframe CPUs), and if it is, a C compiler written for that processor will most certainly use those features too.
Also, looking at the table, they included OS 9. Does that version even have a filesystem permission system or a concept of users? Why don't they just include Win98 too. That's like saying "the building uses empty frames instead of doors. We didn't find any problems with the locks, therefore the building must be secure."
Seems to me, those eyes just found something...
I think you are missing the point. These people are not worried about someone walking in and taking hardware, they are worried about someone sneaking into the system and using it as a zombie or steal information without anyone knowing about it.
You also missed the obvous, this bug can, in theory, be exploited remotly given the right kind of access.
It doesn't really matter how long the bug/exploit existed. What matters is how big of a problem the exploit is and how fast it is fixed. Microsoft tends to take forever to fix it's bugs and it doesn't always do that right. Some patches would undo other patches and one of my friends ran Windows Update and it broke his ability to connect to the Internet.
Why the hell are you comparing a Kernel to a collection of Operating Systems and Operating Environments (Windows 3.X 9X are not actually sperating systems) ?!? Most of the exploits of a Linux Distro are from the third party packages. I don't ever remember seeing anyone faulting Microsoft for a security hole in Windows caused by some third-party software. That Caldara exploit was most likely in a distro package, not Linux. Please get your terminology down before you pretend to know something.To take advantage of the mremap() syscall bug a person would either need to be able to run an executable on the Linux Box or be able to get some poorly written program to do it. And what business do most programs have calling mremap() anyway? This is not an easy bug to exploit. I would say that this exploit is not that big of a problem for most people and was fixed quickly. For people running a system where the admin was stupid enough to give untrustworthy people a login accout or somehow the ability to run executables, well, they should have been expecting something bad to happen.
Yah, and guess where your head is stuck? I'll give you a hint, it's not the sand. :p
"Windows is better because. . .. Linux is better because. . . Mac is better because. . . Whoever sets the terms of the argument always wins (unless that person has no idea how to argue correctly)" -- MrNybbles
Losing faith in humanity one person at a time.
Losing faith in humanity one person at a time.