Slashdot Mirror
Local Root Hole in Linux Kernels
xepsilon writes "A local Linux security hole using ptrace has been discovered that allows a potential attacker to gain root privileges. Linux 2.2.25 has been released to correct this security hole, along with a patch for 2.4.20-pre kernels. 2.4.21 ought to contain this fix, once it is released. 2.5 is not believed to be vulnerable to this security hole. See this email from Alan Cox for details, and a patch."
... must be Microsoft's fault since it's posted on /.
With all the brainpower on /. I'm sure we can discover a way.
Got Root?
And please, allow me to be the first to say:
Holy shit, this could be a problem.
Excuse me while I go patch my servers, which all of my developers have user-level access to, albeit very limited access.
New marketing ploy for TMF: get your security news before the 13-year-old 5<R1p7 <1|)|)135, since they don't have credit cards with which to subscribe.
Jouster
All the regular posters must be patching....DAMN SON
Journal Entries:
(looks at watch) its monday again... time to go patch my IIS
(looks at watch) its tuesday again... time to go patch linux.
It's been /.ed and I'd really like/need to read it asap. Hence I am posting at +2. Karma burning away...
After all, Linux is perfect, right? Linux has NO vulnerabilities. It's that OS from Bill that is buggy, right?
Got an e-mail this morning from Redhat Network that a new kernel was available to solve this vulnerability. up2date got my machine patched hours before the /. post.
If you're running Redhat, RHN is a valuable tool that no admin should be without.
There is no reasonable defense against an idiot with an agenda
:wq
It's a good thing I run FreeBSD.
Ptrace hole / Linux 2.2.25
To: linux-kernel@vger.kernel.org
Subject: Ptrace hole / Linux 2.2.25
From: Alan Cox
Date: Mon, 17 Mar 2003 11:04:35 -0500 (EST)
Sender: linux-kernel-owner@vger.kernel.org
-----------------------
Vulnerability: CAN-2003-0127
The Linux 2.2 and Linux 2.4 kernels have a flaw in ptrace. This hole allows
local users to obtain full privileges. Remote exploitation of this hole is
not possible. Linux 2.5 is not believed to be vulnerable.
Linux 2.2.25 has been released to correct Linux 2.2. It contains no other
changes. The bug fixes that would have been in 2.2.5pre1 will now appear in
2.2.26pre1. The patch will apply directly to most older 2.2 releases.
A patch for Linux 2.4.20/Linux 2.4.21pre is attached. The patch also
subtly changes the PR_SET_DUMPABLE prctl. We believe this is neccessary and
that it will not affect any software. The functionality change is specific
to unusual debugging situations.
We would like to thank Andrzej Szombierski who found the problem, and
wrote an initial patch. Seth Arnold cleaned up the 2.2 change. Arjan van
de Ven and Ben LaHaise identified additional problems with the original
fix.
Alan
---
Hmmm....
A Windows vulnerability is discovered and it takes a week or more to get it taken care of.
The Linux kernel has a vulnerability and the patch is available immediately.
Who's a sysadmin to trust?
d a v e
"Hmmm...upgrades."
And for the hax0rs without a local shell, there's a recent samba instant-remote-r00t vulnerability. Get your patches while they're hot!
Lo-Cal Root Hole in Linux Kernels
I think I saw this in an advertisement for granola.
mmmm... breakfasty
Best Windows Freeware
Red Hat Security Advisory
- up grade/
Synopsis: Updated 2.4 kernel fixes vulnerability
Advisory ID: RHSA-2003:098-00
Issue date: 2003-03-17
Updated on: 2003-03-17
Product: Red Hat Linux
Keywords: ptrace
Cross references:
Obsoletes: RHSA-2003:025-20 RHBA-2003:069-12
CVE Names: CAN-2003-0127
1. Topic:
Updated kernel packages for Red Hat Linux 7.1, 7.2, 7.3, and 8.0 are now
available. These packages fix a ptrace-related vulnerability that can
lead to elevated (root) privileges.
2. Relevant releases/architectures:
Red Hat Linux 7.1 - athlon, i386, i586, i686
Red Hat Linux 7.2 - athlon, i386, i586, i686
Red Hat Linux 7.3 - athlon, i386, i586, i686
Red Hat Linux 8.0 - athlon, i386, i586, i686
3. Problem description:
The Linux kernel handles the basic functions of the operating system.
A vulnerability has been found in version 2.4.18 of the kernel. This
vulnerability makes it possible for local users to gain elevated (root)
privileges without authorization. This advisory deals with updates to
Red Hat Linux 7.1, 7.2, 7.3, and 8.0.
All users of Red Hat Linux 7.1, 7.2, 7.3, and 8.0 should upgrade to
these errata packages, which contain patches to fix the vulnerability.
4. Solution:
Before applying this update, make sure all previously released errata
relevant to your system have been applied, especially the additional
packages from RHSA-2002:205 and RHSA-2002:206.
The procedure for upgrading the kernel manually is documented at:
http://www.redhat.com/support/docs/howto/kernel
Please read the directions for your architecture carefully before
proceeding with the kernel upgrade.
Please note that this update is also available via Red Hat Network. Many
people find this to be an easier way to apply updates. To use Red Hat
Network, launch the Red Hat Update Agent with the following command:
up2date
This will start an interactive process that will result in the appropriate
RPMs being upgraded on your system. Note that you need to select the kernel
explicitly on default configurations of up2date.
Karma: The shiznight, mostly because I am the Drizzle.
1 - No central reporting site that would tell you. Pretty much ad hoc , "I happned to read it on Slashdot."
2 - Hackers now know the same time sys admins do.
3 - Rebuild the kernel for all new drivers for every machine (hopefully they're in synch) in your company. Woo hoo!
4 - ???
5 - Profit!
(Server Room, DP) A hole was found in 'cypress', one of the principle Linux file, email and web servers of Brapco Corp early today. "We were dusting out around the back", said Mike Koyro, IT manager of Brapco, "and there it was, right by the power supply." The hole was quickly verified by other members of the IT dept as "really there". Speculation that it may be a screw hole was quickly dispelled when Frank, chief scripting officer, pointed out it didn't have any threads, and no screws were found loose anywhere nearby. "If someone got in here and drilled it during the night, they sure did a clean job - there's no shavings on the floor and the hole has no burrs" observed Mike. "It was either a professional job, with a sharp bit and machining oil, or a manufacturing defect". Calls to Linux Security were unanswered as of press time.
try { do() || do_not(); } catch (JediException err) { yoda(err); }
Haleulia and pass the green beer. It's not in Welsh.
BTW: If you haven't read, or tried to read, Alan's blog you won't get the joke.
--
# Canmephians for a better Linux Kernel
$Stalag99{"URL"}="http://stalag99.net";
Soooo, i wonder how many posts will appear here along the lines of those in the WebDav exploit story earlier. Not many im willing to bet.
Those people willing to shout and hollor at every serious issue, screaming bloody murder because someone got it wrong, really pisses me off. Yes people get it wrong, they write insecure code from time to time. This issue and a number of those before it show that Linux has as many opportunities for exploitation as any other OS.
I guess they were just trying to out-do the IIS hole.
... there's always "linux single" ... :)
Ah well
Are there any know exploits for this yet? Has anyone scene this in practice?
Rus
Cheap UK and US VPS
This is already at least the second problem somehow connected with ptrace() in the kernel. Kernels prior to 2.2.19 were vulnerable to a race-condition attack, that enabled local users to gain root privilegies. This was one of the most "famous" problems in last years and it's known as the execve/ptrace exploit.
More details:
This vulnerability exploits a race condition in the 2.2.x Linux kernel within the execve() system call. By predicting the child-process sleep() within execve(), an attacker can use ptrace() or similar mechanisms to subvert control of the child process. If the child process is setuid, the attacker can cause the child process to execute arbitrary code at an elevated privilege. There are also other known lesser security issues with Linux kernels prior to 2.2.19 which have been noted as fixed.1) umm, I got a mail from redhat about this same as I get something from MS.
2) I think you worry about crackers knowing not hackers, hackers fix problems like this. Also as anyone in a production environment knows just because MS does not publish it does not mean that people dont know before they have a fix. Also the time to deploy a MS patch in production is much longer due to shutdowns and testing.
3) As opposed to almost *ALL* MS updates which requres a restart of every server in your company Woo Hoo!
4) ??? 5) Profit
I don't know. Let's ask the U.S. Army what they think of Microsoft after the latest server hacking.
I do not have a signature
However, quoting some guy further down the page:
A Windows vulnerability is discovered and it takes a week or more to get it taken care of.
The Linux kernel has a vulnerability and the patch is available immediately.
It may be old, but it's still useful.
But at least they admit it when there are problems. As does the BSD crowd too.
And *nix is still a hell of a lot closer to perfect..
---- Booth was a patriot ----
English is my second language, but I`m pretty sure
it should be erroneous.
Or was that on purpose? That`d be funny.
Linux has security problems? I've been reading this site for so long, I thought that was only in Microsoft's domain.
Cause if it is >1 day and you offer shell accounts, you are gonna get hax0red!
muhaha, as every multi-user linux box in the world has to reboot and lose their uptimes.
These annoying cut'n'paste trolls really annoy me, they are far worse than all the 'normal' trolls.
Count the number of karma whore posts this cut'n'paste kid has done recently.
I know I'll get modded down, I don't care I deserve it. -1 flamebait, -1 troll.
Someone got into /.'s and is searching for tech jobs!
I hate to say it, but this is kind of refreshing. This ins't a troll, so don't get me wrong...I'm a linux user myself. But after seeing the masses rip into MS yesterday when the thread about the IIS 5.0 hole was posted, I got a tad frustrated. Granted, I hate Microsoft as much as the next guy, but this just goes to show you that it's NOT just Microsoft that falls prey to holes and exploits. If it runs an OS, there's a chance it'll be cracked. Simple as that.
Hell, the linux kernel is without a doubt one of the most audited open source projects out there, and this bug STILL didn't surface until 2.4.20. Of course, I applaud the speed and availibility of patches and workarounds to the bug. Just remember, it happens to everyone.
"Hell hath no fury like a woman scorned for SEGA. ..."
"Remote exploitation of this hole is
not possible."
Does that mean you have to be at the keyboard, or does that mean you have to have access to the box itself? (a shutdown/restart exploit?)
am i affected if i run the grsecurity patches and disable ptrace for non root users?
I hate when I choose to reply instead of mod, but this needs to be said - they aren't the same!
I am not going to patch my Linux systems. Why? Because it isn't possible to exploit this vulnerability remotely. The only local user on my machine knows the root password (me). So it isn't quite the same severity as a bug in a widely distributed webserver. Yes, they are both serious, but compare apples to apples. (not that your comments aren't correct, just that you need to make them at the right time.)
My beliefs do not require that you agree with them.
Yeah but has the patch been properly regression tested and backported to all versions? I know the instant I update a new kernel from RHUpdate I'm going to have to compile new drivers / stuff that's specifically dependent on older kernel versions (yeah stuff is dependent on 2.4.9 for example) is going to break. Linux kernel patches are usually a nightmare.
This is slightly of topic, but I have a question about these exploits. I'm not exactly sure how these things work...
Buffer overflow in WebDAV? Then here's an Administrator logon!
I don't know how this ptrace vulnerability works either, but is there a general rule for what makes an unchecked buffer yield the ability to execute code of your choice on a vulnerable machine?
OMG! Wau!
Once the patch is installed, is there any way I can be sure my system hasn't been rootkitted without doing a clean install?
Jason
ProfQuotes
As a linux newbie is there an easy way to find if my kernel is vulnerable to exploits?
I run debian woody and can do apt-get update,upgrade but that wont update the kernel will it?
Thanks for any help.
Bush and Blair ate my sig!
a consultant doing some contract work for us gave himself root access. Fortunately, we would make big brother look lax, and had him arrested. :)
2.5 is not believed to be vulnerable to this security hole.
Is this along the same lines as "we don't think this will kill you"?
I browse Slashdot at +3, Funny
We would like to thank Andrzej Szombierski who found the problem, and
wrote an initial patch. Seth Arnold cleaned up the 2.2 change. Arjan van
de Ven and Ben LaHaise identified additional problems with the original
fix.
It keeps repeating ever and ever again:
Even before the official patch for [insert generic sec. vuln. here] was released, there were patches. Even before I could read about it, there were patches. Even before [insert generic script-kiddie here] >can compile a exploit, there is a patch there. Thank OSS, learn [insert generic software enterprise] what is real customer support!.
To NT Sysadmins: Dont try to troll, since now in two months there will be a worm exploiting WebDAV-w2k vuln all over the world (a la code-red, slammer, etc...)
Now, lets go patch those machines!
------- The last Sig. got fired.
Anyway, another copy of the patch.
- Sam
The secret to enjoying Slashdot is to realize that it should not be taken too seriously.
If you choose to let local users get root, then you need to be extra careful about your remote vulnerabilities, because now remote non-root holes are remote root holes.
Are GRSecurity patched kernels vulernable?
If you can't patch this right away, you can easily work around the hole. In order to be vulnerable, you need to have kmod enabled in the kernel, and /proc/sys/kernel/modprobe must contain the name of ANY VALID EXECUTABLE. It doesn't have to be /sbin/modprobe. Even /bin/false is vulnerable on this one.
/this/file/aint/there > /proc/sys/kernel/modprobe
To prevent the exploit, give the kernel a bogus filename to use as modprobe, like this:
cat
If you only use kmod to load modules at boot time, you might consider having this run after all your other init scripts, say in rc.local.
Pat
Well Linux is more along the developmental side of unix, if you want security, try OpenBSD.
(On a side note, if you are going back to windows, you probably weren't serving any other users, so what is wrong with a local root hole, afraid you might slip up and root yourself? Yes, it is still an issue, having a local root hole, but if you know what you are doing, it shouldn't be too rough.)
No, it's just that you're inept.
Hmm...seems to me that either way, time would be needed to fix it. *Someone* knows about it earlier than the patch (unless somehow Linux is magic and codes up a patch as soon as some lonely hacker recognizes an exploit). Perhaps it's a matter of "hey, there's a bug here" vs. "hey, there WAS a bug here, but I fixed it" type news. Either way, there are unpatched systems worldwide that may never get patched, and whole lot of patching to be done for those that will be.
Those wanting to exploit such a problem are obviously going to stay quiet about it.
Wow! Is it 2003 all ready? :D
The only thing that will stop you from fulfilling your dreams is you. - Tom Bradley
Your spelling of erroneous is correct. Your spelling of ahem is suspect. :)
Mod Parent Up for hilariousness of truthfullness.
Sig & Below
Yuck Fou
The difference in this case is it's a kernel exploit. Unless the problem lies in a module, you'll still have to reboot. :/
What's this Submit thingy do?
Will Ximian's red-carpet patch this?
This sig no verb.
This one seems to make a cleaner text patch than the last one I linked to.
- Sam (compiling the kernel as we speak)
The secret to enjoying Slashdot is to realize that it should not be taken too seriously.
cuz you're a retarded idiot if you're still using the 2.3 development series
Linux kernel patches are very rarely that bad, not to say that I like them either. So long as your kernel minor version number doesn't change and you're using loadable modules, there's no need to recompile any existing drivers. However, you DO still have to recompile the kernel, drop it into /boot, AND reboot which DOES mean you will lose any uptime bragging rights you were saving for your performance review.
Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws-Plato
I'm pretty confident Bill Gates coded this part of the kernel secretly...
Sig & Below
Yuck Fou
How funny -- think of all your machines with enormously high uptimes that now you have to reboot if so many as 1 solitary untrusted user has access the machine. Ah well; So much for my 955 day uptime.
15:40:55 up 15:12, 16 users
And of all updates for a Linux server what % of them are Kernel and require a reboot? as compared to Windows which almost all updates require a reboot.
Until the patch has been tested and distributed, you can prevent the bug from being exploited by locking the door to your office.
If you are at the keyboard, you can usually get root instantly on Linux. "lilo: linux single"
At least in Debian, even with "linux single" you have to type the root password to get root. And any installation with the least pretense of security has always disabled user parameters for LILO, of course. Just like it had to disable e.g. booting from a disk.
-- Repeat with me: "There is no right to profits".
What, exactly, is this bug? I remember one a while back where you could ptrace an app that had a saved uid of 0 and keep the trace once it ran seteuid(), is this the same?
With so very many vulnerabilities (and ever expanding), it's easy to see why you'd assume that Windows was the only buggy vulnerable bloated operating system. This isn't true. It just seems that way. It feels that way. And, considering how wide rangingly destructive Windows vulnerabilities tend to be, for all intensive purposes, it is that way. But, deep down, we all acknowledge that it isn't technically true.
You obviously have a very short memory. Just wait till the next MS bug. You'll hear the Zealots (TM) exclaim how Linux is so much better, it would never happen on Linus' watch.
Seriously, keep a Post-It about this on your monitor. You can deliver a pound of flesh then.
Geez, only took /. 27-odd hours. Anyway.
...) a uid 0 modprobe (easy enough way to call kernel_thread()), but for some reason, the traced process isn't properly reparented, so all subsequent ptrace() calls fail. (Whenever you PTRACE_ATTACH to a process, it's supposed to become the child process of the tracer, and ptrace_check_attach (linux/kernel/ptrace.c) will return -ESRCH if this condition isn't met.)
I tried writing an exploit for this flaw, but I couldn't get far enough to inject any code. I managed to ptrace(PTRACE_ATTACH,
I'm not positive this is actually exploitable, but I'm not positive I took the correct approach, either. In any case, the most I've been able to do is spawn a slew of suspended root-owned processes. Not good, but not the end of the world, either. If someone has actually managed to exploit this flaw, I'd love to see some code so that I could see what I did wrong. Conversely, I'm willing to share the code I have upon request. I've only written code up to the current impasse, but once past this problem, the rest should be pretty trivial.
St. Patrick's Day, a perfectly valid and socially acceptable excuse to get rip-roaring pissed, and you say it's *only* for the Irish? I'm sorry, please hand in your geek membership card. You aren't allowed to post here anymore.
SQUEAK, the Death of Rats explained.
1. get email from redhat 2. upgrade kernel 3. reboot 4. see story on /.
5. ???
6. PROFIT!
anyone aware of anyone working on backports of this patch, at least for the 2.2.x series? or anyone aware of a patch that fixes this specific problem on 2.2.x? (rather then 2.2.25 which may have a bunch of stuff unrelated). the alan cox email site seems to be slashdotted.
After the last ptrace() fiasco, there was a temporary workarounds in the form of loadable modules which stub out or wrap the ptrace function. For servers where downtime and reboots must always be scheduled in advance, such a fix was well received.
You can create such your own module containing a do-nothing fake_ptrace function. In init_module(), set sys_call_table[__NR_ptrace]=fake_ptrace so the fake ptrace gets run instead of the real one. Search google for "no ptrace module" to find a few readymade ptrace wrapper/stub modules.
For the most part you're correct, but then you run into certain drivers which are commercial and require specific kernel versions. Also drivers which require patches to the kernel and are released w/patches for say kernel 2.4.9 but not later versions.
Yeah these things do exist, and yeah it sucks that not all drivers are open source (maybe because, gasp, people have trade secrets!) But patching your system should not break backwards compatibility. Especially with the Kernel being the moving target that it is.
Great a patch was release in one day.. Regression testing muts have be done over lunch. The box didn't crash, so the patch must be ready. Then release it, and all the "experts" can update there kernel.. Then the page with the patch information is slashdotted and no one can get to it..Wonderfull. But wait I boght my linux machine at Walmart.. how do I update it.. No one sent me an email..I don't know what www.slashdot.org is.. I/m still pissed because Walmart doesn't stock any good linux games.
You can see the message here or download the patch linked from this email here
Personally I think I'm going to wait for a proper version of the kernel to come out, (and hope it does).
I wonder how well smatch/stanford checker could check for similar conditions.
People who disagree with you are not automatically evil, greedy, or stupid.
It fails on include/linux/sched.h with default patch options. Which kind of sucks. You can get it to 'work' by giving patch a fuzz-factor of 3, but then the build fails. Not a very usefull patch. /usr/src /otherhome/stor/src/linux/linux-2.4.20.tar.bz2 | tar xv
cd
mv linux-2.4.20 linux-2.4.20_OLD
bzcat
cd linux-2.4.20
patch -p1
fails at include/linux/sched.h
If you do 'patch -p1 -F 3' instead, it won't fail, but the fuzz factor obviously leads to a patch error, as the compilation breaks [as soon as include/linux/sched.h is included, BTW]
I mean, I appreciate knowing that my system is horribly vulnerable, but a WORKING FIX would sure be nice.
---
the pen is mightier than the sword, the sword is mightier than the court, the court is mightier than the pen.
How easy is it apply the patch? What does it change? How will it effect other things.
You could (theoretically) just apply the patch by Mr. Cox, recompile, re-install and you're done. You know exactly what's changed, and that change will not effect anything else.
Some (though not all) MS patches break things and do things that you don't know about. If you apply a binary patch what does it change? You no have to way of really telling.
With a kernel patch you also only have to reboot (ideally) once. Some MS patches take multiple reboots, which is down time.
There is also the fact that the license terms aren't changed with Linux. With SP3 for W2K, and SP1 for WXP, all of a sudden you're allowing MS to do things to your system which it wasn't allowed to do.
Go ahead, auto-update with Windows. But what happends when it installs something you don't want?
You ask what the differences are: those are some of them.
Yeah - no shit.
No security through obscurity.
The bgs are found FAST and are PATCHED FAST. If your lazy 200-lbs fritto-lay-eating "sys admin" thinks its above his ego to patch his systems up, that his problem.
Where the hell are the debian people with a patched kernel? The patch alan cox provided doesn't apply cleanly to the debina modified kernel, so I am trying to hack it up now. But shouldn't someone in charge of security patches at debian have done this and had an update out?
COME ON WAKE UP!
http://www.chkrootkit.org/
Unless they've messed with the libraries (replaced them, or do a PRELOAD=/lib/.kit/hack.so) and have a ps(1) hidden someplace else.
/dev/.rootkit/ps instead.
/dev/.rootkit/{netstat|ps}.
You can set things up so that when an execv(2/3) occurs, check the strings for "ps", and then launch
There's also replacing the shell so always runs
The only way to verify things is to boot from known good media (CD-ROM), and run a check between all binaries/libraries on disk, and a known good checksum database.
Ah, but theoretically, if you were still to use the 2.3 kernel series, you would not face this hole, so what's retarded in that!?
Murphy's Law of Research: Enough research will tend to support your theory.
Once again Slashdot shows it's integrity by SLASHDOTTING THE FUCKING PATCH.
Did you ever hear of MIRRORING? Or maybe notifying the uplinked site that they are going get HAMMERED?
Obviously the kernel provides access control to a copyrighted work (the Linux kernel, and all apps on the system). Therefore by providing this info, he is disseminating a mechanism to bypass said access control. Therefore he is in violation of the DMCA!
Go ahead an call me a troll, but he did say that's why he wasn't ever setting foot in the US again!
modprobe -f, and if it fails you have to contact the vendor and bitch until they fix it.
Trade Secrets? In a driver? Pull the other one!
How the hell do you know that? If 2.2 is vulnerable, and 2.4 is, why wouldn't 2.3 be?
The reason why 2.3 isn't mentioned is because you're not supposed to be using it. People do have a valid reason to use 2.5, but not 2.3.
Retard.
I know "Cymru" means "Welsh" but that's about it.
:o)
Tux, the beloved Linux mascot is Welsh!
It's true! Tux is a penguin..
Penguin is derived from two Welsh words: Pen (head) and Gwynn (white)...
So (besides Alan) there is another link between Wales and Linux.
(That, and I've tripled your knowledge of the Welsh language
What about 2.0.x? Are they okay?
Prevent email address forgery. Publish SPF records for y
I think our friend Al Viro would have something to say about the auditing level of the Linux kernel. And if we're talking about drivers/ in particular, it would probably involve the words "obfuscated", "brain dead", "steaming pile of shit", "warped beyond all belief" ... :)
Linux code gets a fair amount of review. But once it's there, there really isn't any auditing at all.
Could this have been the portion that was copied :)
over from SCO's IP?
Guess the astrotufers feelings where hurt.
I'm new to Linux, so I might be wrong, but: If the minor version 2.x is odd, its a development/beta/alpha/whatever kernel. So 2.3 became 2.4, and no one should be using 2.3 on a production box. 2.5 is the current development branch, and when it is final it will be renumbered to 2.6. At that point no one should be running 2.5 on any box that matters.
Vote for global prefs bug
One of the interesting parts of this article is where they say the Trip Hawkins era of Electronic Arts has been pretty much deleted from history.
I remember those days. Say what you want about Trip (and you could write books on the guy), Electronic Arts circa '83-'86 was something quite special. They were ground zero for unbridled creativity in games for home computers. For all you veterans of the 8-bit era, think about it...how many of your favourite games came from EA? M.U.L.E...Racing Destruction Set (imagine THAT updated ona console!)...ARCHON...the list goes on and on. Heck, EA was the original publisher for a little known crew of programmers known as Interplay, giving us the legendary Bard's Tale and Wasteland. Those were the days. Just the site of that colour-cycling EA logo during bootup was enough to get my heart pumping.
Heck, EA even pioneered new and horrible ways of copy protecting software in those days...us old Commodore 64 users certainly remember the grind-stutter-stutter-stutter sound of EA's copy protection on all their games. Strange how history repeats itself and we see the industry doing the same sort of stuff with SafeDisc (I keep waiting for my CDROM drive to make that stutter sound).
And it's easy to forget those wonderful days when you consider what a monstrosity EA has become (popular rumour states that Richard Garriott modeled the nefarious Guardian after Trip Hawkins).
You will deploy Linux patches on production machines without testing?
MSDOS: 20+ years without remote hole in the default install
does this affect monolythic kernels? as in a kernel you cannot load modules into.
slashdot: where everyone yells sarcastic metaphors to themselves to understand the issue
This isn't a race condition with ptrace and execve, this is the kernel not handling threads properly with ptrace.
... packetstormsecurity.nl has a kernel module that disables ptrace for all users other than root (aptly named "ptracekm") ... and users of grsecurity with randomized pids turned on should be safe as well, since the exploit assumes child = mypid+1
That being said, there are mitigating factors
True, except here it basically says if you expose samba/CIFS in general, you're fuxored.
"The SMB/CIFS protocol implemented by Samba is vulnerable to many attacks, even without specific security holes. The TCP ports 139 and the new port 445 (used by Win2k and the Samba 3.0 alpha code in particular) should never be exposed to untrusted networks."
So all they've done is release a patch for what can be fixed WITHOUT breaking Windows integration.
"I can't give you a brain, so I'll give you a diploma" - The Great Oz (blatently stolen sig)
I used to try soem of the others, but Slackware is just fine, just perfectly fine. Thanks for not cluttering it up with candy from the gedunk.
Everyone's taking comfort in the fact that no remote exploitation is possible, but remember all those universities that you've convinced over the past few years to switch from proprietary UNIX to Linux for their cs department and mail servers? The ones with thousands of local accounts given out to all the students and faculty? Yeah, they might not be happy about this.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
1 juz7 707@llY g07 r007 4cc3zs to /\/\y box!
Oh wait, I had root access. Crap.
only myself and the IT manager are able to log into our system ( everyone else has /bin/false ) so as long as no one kicks in my office door or guesses our root or admin password i feel safe.
and no, i will NEVER be giving shell logins to our users ( shiver )
If you mod me down, I will become more powerful than you can imagine....
This just goes to show Linux is Dying.
Courtesy of someone sick of the BSD dying trolls.
I second that opinion. However, many sysadmins have a responsibility for public servers (lots of ports open even with a firewall). As such these same sysadmins are smart and have a redundant box to do things like patch a system.
In addition, some small businesses don't have the luxury of a secondary box or even an IT specialist that can put a machine through a high-load test for more than a few hours at a time -- let alone having to patch it at all!
Ideally we would all have a RAID 10 array connected to four boxes each running a different OS. While some companies (!) may have the time and money for this, the small folks like mom-and-pop stores can't afford the expense of time or money.
$DEITY bless $NATION
Never forget that proprietary, commercial UNIX solutions are also vulnerable to kernel-level bugs and exploits. I used to work for a university that deployed Linux and Solaris solutions - the patch sets for Solaris (kernel and userland utilities) were just as necessary as the Linux server installations.
The beauty of the Linux and open-source worlds is that the code is available right before your very eyes and is subject to scrutiny, day-in and day-out. Commercial offerings are not available to the general public, potentially leaving behind bugs that wouldn't be caught by the few who _could_ see the code. Code that is viewed by literally thousands of all programming backgrounds, versus code that is viewed by a select few which only specialize in that code, is more likely to be exploit-free.
This particular Linux kernel exploit was encountered by developers that recognized the flaw. And, luckily for us, the developers were talented enough (or knew someone in the core development group) that could quickly produce a patch so that administrators could secure their servers from being taken advantage from.
If the exploit was encountered in the commercial arena, the person who found the flaw would have to contact the company who supports the operating system. An assessment team would have to see the cause/effect/consequences of the exploit. Then, the development group would have to produce a patch. The company would then contact their support group to contact their enterprise customers first (more than likely) to deploy the patch. Finally, with the company's core customer interests intact, the company would publish their findings and solution for the remainder of the world. Many Microsoft patches are first released to their core enterprise companies - and then released via Windows Update (or through their web site).
For universities that have made the switch, there should be more peace of mind knowing that the quantity of security breaches on the kernel level are much less than the overwhelming number of Windows flaws (which generally require a reboot) and at a much cheaper price than a commercial UNIX offering.
Ayup
I have found a new root exploit in linux. Please apply my patch to fix the problem. Nice way of getting someone to install a backdoor on your linux kernel. Someone should exploit this way of attacking a linux machine. Billg are you listening..
redhat is free for download, windows isnt. they have to make money somwhere along the line.
Of course I will test, but the testing almost always takes less time because it does not break other services. When we had to patch windows to avoid all the SQL server crap a while back it broke the damn server, so in testing there is going to be more tweaking involved than one might have with a typical Linux patch..
If you don't have the ptrace prog on your systems, or you make it not setuid (if it is anyway) does that make a temporary fix?
Get your own free personal location tracker
These come up so often, I thought this story was a /. dupe at first glance.
Why bother.
Unless however you happen to do something REALLY stupid like allow you users to run their own CGIs. Whoops. Now they've got root. Assuming their CGIs have a flaw that allows an attacker to run an arbitrary command (as the web server user, usually nobody), now an attacker has an exceptionally easy way to get root.
Or even better and by far more common. Do you or someone you know allow users to write to their own .procmailrc? Is so, then they've got root. All you have to do is allow your user to write to/over that file and they own you. Dumb dumb dumb.
Of course, it is good that these kinds of bugs get fixed. Some people do run multiuser systems, and it provides an additional barrier against intrusions. But don't lose any sleep over it.
Incidentally, these kinds of exploits are probably rampant on Windows systems; there, people don't even bother looking for them because there are very few multiuser machines and most people have local Administrator privileges anyway. Also note that Microsoft didn't even try to get Windows certified secure for multiuser use.
to linux-2.4.20
---
the pen is mightier than the sword, the sword is mightier than the court, the court is mightier than the pen.
I agree with you, though I don't think those statistics are readily available.
Heck...under Windows, even video game installations tend to demand a reboot. (Though you can usually get away with saying No and running the game anyway.)
This is because most software applications include DLLs that get added to system directories, and, technically, you're supposed to reboot in order for those DLLs to be recognized and harbored by the OS.
Under UNIX (NOT just Linux), You only have to type ld as root, and you should be just fine. Special integration with things like Mozilla or Emacs may require you to restart the program, though.
I suspect UNIX's resiliency is partially the result of IEEE's efforts in developing POSIX, etc.
What's this Submit thingy do?
A webserver that allows users to run their own cgi-scripts could very well be in trouble, and so could a mail-server letting users at their .forward and .procmailrc files.
Don't assume you're safe just because you dont have any shell users.
Man, the *nix systems are always so buggy. So many bugs. Unfortunately the entire community is headed up by one guy so I can't make it his fault.
:).
OTOH, I could blame Trovald - The selfish leader of the entire OSDN community.
J/K
While its not really kosher to bash an OS because of a single flaw, there is a fundamental difference in the case of this flaw and the previously announced IIS exploit: this one's not yet exploited. One thing that hurts FS/OSS on bug lists is that all *potential* exploits in open code will be listed as bugs, while many proprietary producst only disclose known, possibly exploited, bugs. Case in point, the IIS problem was exploited almost a week ago. The kernel problem was noticed, fixed, and no exploit exists. In fact, a previous poster on this board has posted his inability to trigger the *potential* exploit and asked for help.
I always get the shakes before a drop.
Man all the *nix systems are so buggy. So many bugs. They are so inefficient. Unfortunately, the entire *nix community is not headed up by one guy so that I could make it his fault.
:)
OTOH, I could blame Trovald.
J/K
Anyone know how to check whether my server has this problem? Or alternatively, does anyone know whether the Grsecurity patches for 2.4.20 (as included in Gentoo's kernel) fix this hole?
OpenBSD isnt vulnerable :P
... that I am using Windows instead. /joke
When setting up security, I always assume any local user can get root priviledges and make sure I don't care that much. It makes life much easier and less worrisome.
Man being a linux newbie I was a little freaked about this since my understanding of patching a kernel involved getting all the patches along the way since the release of the kernel I'm using and installing them one at a time. Well rpm -ivh or -uvh /boot/grub/grub.conf file and now both kernels are there.( I did rpm -i instead of rpm -u) This was about as painless of a fix as I could imagine. I am so glad that I didn't have to install every patch from version 2.4.18-14 to 2.4.18-27, that would have really sucked the root(pardon my pun)
sure beats the crap out of that. Took me all of two minutes to find the rpm on the redhat site and install it. I didn't know if it took so I looked in my
This is probably way too late in the discussion to get seen, but Alan's patch won't apply cleanly to 2.4.20.
A clean patch can be found here:
0 -ptrace.patch
http://www.hardrock.org/kernel/2.4.20/linux-2.4.2
Sorry if you get /.ed.
Have you considered the possibility of someone exploiting a non-root remote hole on your box and now having the ability to escalate themselves to root?
Yes I have. The thing is that this assumes several things that may or may not be true. There are risks involved in this approach, but I am running my email server, etc. and can't afford the downtime if something goes wrong. Also my kernel is highly customized, so moving to a new version of the kernel is difficult, time consuming, and I don't have a testing system, so if something goes wrong, I may not see it until it is too late.
Instead I am focusing on the security perimeter-- making sure the web server, ssh, and email server are secure, etc.
Basically I see this as a contributing issue not a primary one. And at this time, I thing it is too soon to patch for me.
LedgerSMB: Open source Accounting/ERP
Um, no, I'm afraid the guy (Rain) _does_ know what he's talking about (since I know him), and I've done a fair amount of kernel hacking in my day.
3 03 .2/0271.html
If you'd actually like to read something on-topic, see Ben Pfaff's response to Alan's post. The short of it, "we're [i.e. you're free to do it!] working on a correct fix for all cases, this is just the quick sledgehammer."
http://www.uwsg.iu.edu/hypermail/linux/kernel/0
Wrong. "local" in this sense means able to run a shell under any UID. Yes this means any user with an account may be able to escalate to root. It also means that any non-root hole can probably then be escalated to root.
2. That doesn't only encompass flawed daemons (apache, bind ... all run as non-root), it includes poorly written CGI/php and other server parsed scripts. If a script allows remotely controlled data to be passed to a shell, that's now a potential root compromise.
2. Plus this flaw probably isn't countered by any of the various approaches to kernel hardening (gr-sec and the like).
So it's potentially serious if you weren't serious about security of your Linux servers.
Now let's look at the current understanding of the "WebDAV"/IIS exploit
I think it's already well known that the this was discovered *after* an army server was compromised. If you don't already believe that Opensource works better then my $0.02 probably isn't going to convince you, however *very* few *nix problems are found *&* applied by the vandals before a patch is available / developed.
1. Because by *default* IIS is installed on w2k servers, and installed with Administrator (root) access, many IIS boxes are rooted.
2. Yes the Lockdown tool is supposed to fix this, however it's being reported that it doesn't in all cases. Thus the patch is strongly advised, whatever workarounds you're using.
3. The actual flaw is in ntdll.dll This library is loaded by nearly every process running on w2k.
If they're wrong it's going to be a nightmare. Even if they're right, it's pretty darned bad.
Sure, security is a process, not a product, but part of that process is choosing systems that you actually have some ability to evaluate and predict and manage problems.
Linux is Linux, if One need clarify their dist: <Dist>/GNU Linux
bsds are of course just BSD
Sa is for First Post
Su is for Profit
Further in the thread, there is a patch against 2.4.20.
I am using the grsecurity patches and have always had the "restricted ptrace" option turned on (only root can ptrace). Does this provide some (any?) protection against this vulnerability?
nt
Yeah, no kidding. That one wasn't even worth refuting. BTW, I'm still not dead yet!
Karma: Undead.
Boy would this open source developers give it a rest. Let atleast one or two exploits get exploited. This makes for slow news when we all we hear about is it being discovered. I say Alan should sit on it for six months or so, really see if something news worhty comes of it.
Ils sont fous ces américains
It is possible to exploit this remotely, in the sense of "over the internet, thousands of miles from the vulnerable box." It's not possible to exploit it remotely, in the sense of "just a user on the internet who knows your IP." The "local" here refers to the fact that the exploiter needs to have a local account on the system already; this exploit will allow the unprivileged local account to illicitly elevate itself to root privileges.
So don't panic if you're just running a desktop machine, but if you're running something like a university cs department server, where thousands of people have local accounts (and thus now potentially root access), some panic (or quick patching) would be in order.
10 PRINT CHR$(205.5+RND(1)); : GOTO 10
Whew I just forgot my root password
Why do you want your second language to be erroneous?
Yeah, what's my name?
I found http://oxcart.xcalibre.co.uk/~kyle/ptrace24.c lying on a webserver I maintain about 7 hours before I heard of this exploit. Does anyone reckon the two are related?
I guess it's Tuesday today, time to patch the Linux box again
Since when having a security problem became a required feature for desktop OS?
Oh... never mind!
To quote from thge LATIN
pinguis, pingue, pinguior -or -us, pinguissimus -a -um ADJ
fat; rich, fertile; thick; dull, stupid;
Thanks for the reply
Yeah, this is flamebait, but I have to let it out.
./ers do when M$ is found to have a security flaw? Rip on M$!! ..and what do ./ers do when Linux is found to have a security flaw? Rip on M$!!
So what do
The exploit doesn't seem to work on every kernel. I've tried two, Gentoo's 2.4.19 and a lightly patched 2.4.20, and only the latter was exploitable.
My best guess is that Grsecurity prevented it from working, or at least changed enough things to stop the standard exploit. It might be worth looking into, to prevent future bugs like this.
HJ Hornbeck
Alan's Patch does not apply cleanly to 2.4.20. This one should.
--
http://www.niconet2k.com
I guess opinions are divided on this comment!:
/. needs a 'heavily moderated'-metric so that is becomes visible to the readers when moderators disagree. news.yahoo.com has it.
Insightful, Funny, Redundant, Overrated and back to Insightful...
Perhaps
Re:To all the windows bashers..., posted to Local Root Hole in Linux Kernels, has been moderated Insightful (+1).
It is currently scored (2).
It may try to talk like a duck, posted to A Slightly-Softer Microsoft Shared Source License, has been moderated Funny (+1).
It is currently scored (2).
It may try to talk like a duck, posted to A Slightly-Softer Microsoft Shared Source License, has been moderated Redundant (-1).
It is currently scored (1).
Re:Absolutely one step closer!, posted to A Slightly-Softer Microsoft Shared Source License, has been moderated Overrated (-1).
It is currently scored (0).
Re:To all the windows bashers..., posted to Local Root Hole in Linux Kernels, has been moderated Insightful (+1).
It is currently scored (3)
--- Hindsight is 20/20, but walking backwards is not the answer.
You can find a patch for kernel 2.4.20 here :4 .20 -ptrace.patch
http://www.hardrock.org/kernel/2.4.20/linux-2.
I don't really know if it's as stable as it has to be but it does the job it has to do.
Definitions definitions. What I think you are doing there is defining God into existance by weakening the normal monotheistic defintion - that God is the one monotheistic god (a tautology), with real power to do stuff as shown in the Bible and is still doing stuff today, as claimed by monotheists.
It seems to me that with God being just something that people blame for events not caused by obviouse things, there doesn't necessiarily have to be any existance in your definition, just the act of blaming. ;-0
Oxygen is a very toxic gas and an extreme fire hazard. It is fatal in
concentrations of as little as 0.000001 p.p.m. Humans exposed to the
oxygen concentrations die within a few minutes. Symptoms resemble very
much those of cyanide poisoning (blue face, etc.). In higher
concentrations, e.g. 20%, the toxic effect is somewhat delayed and it
takes about 2.5 billion inhalations before death takes place. The reason
for the delay is the difference in the mechanism of the toxic effect of
oxygen in 20% concentration. It apparently contributes to a complex
process called aging, of which very little is known, except that it is
always fatal.
However, the main disadvantage of the 20% oxygen concentration is in the
fact it is habit forming. The first inhalation (occurring at birth) is
sufficient to make oxygen addiction permanent. After that, any
considerable decrease in the daily oxygen doses results in death with
symptoms resembling those of cyanide poisoning.
Oxygen is an extreme fire hazard. All of the fires that were reported in
the continental U.S. for the period of the past 25 years were found to be
due to the presence of this gas in the atmosphere surrounding the buildings
in question.
Oxygen is especially dangerous because it is odorless, colorless and
tasteless, so that its presence can not be readily detected until it is
too late.
-- Chemical & Engineering News February 6, 1956
- this post brought to you by the Automated Last Post Generator...