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."
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
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...
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
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
---
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.
(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
When does it take a week? The WebDav exploit? That's because blackhats found it... They usually don't disclose.
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.Perhaps a better question to ask would be "Would this bug have been discovered had the source not been open to the public?"
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.
We're not patching, we're in denial.
____
ATS11=0 the secret to beating everyone else to a 1 line board.
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.
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?)
Who's a sysadmin to trust?
Ummmmm, Ghostbusters?
KFG
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.
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!
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
Anyway, another copy of the patch.
- Sam
The secret to enjoying Slashdot is to realize that it should not be taken too seriously.
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
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.
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.
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
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.
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.
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.
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.
Linux has security problems? I've been reading this site for so long, I thought that was only in Microsoft's domain.
We do want to make Windows users feel at home as they migrate to a Linux desktop. We don't expect 'em to go cold turkey right away.
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.
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.
If you have 955 days of uptime, your kernel does not have this vulnerability. Of course, it might have others. :-)
That's true in general. It's always much easier to hack a box the closer you are to it. So you should generally seek to prevent vandals from "getting close".
You should always assume that there's a root exploit available when attempting to securing Unixen.
A Pirate and a Puritan look the same on a balance sheet.
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!
Its bugs from code Billy-boy wrote under a pseudonym
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.
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!
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.
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
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)
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
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....
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
Yeah, that William H. Torvalds III has done a lot of damage with his weasly little kernel hacks, dammit.
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.
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?
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.
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
I just assume if someone gets a user account on my machine my entire network is fucked anyways.
Come on, it's not that hard to set a root password.
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.
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
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.
.rc files, this is a problem, but not one without workarounds.... Usually people don't see it worth it and just give shell access....
OK-- in these cases, the users probably have some sort of shell access. Or maybe they run FTP.... In which case how secure is that? Can one get it to execute a shell if there is any exploit there?
And regarding the
LedgerSMB: Open source Accounting/ERP
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
bet you havnt been on the #linux channel in the early days of efnet IRC?
/dev/null]
stuff like that used to happen all the time...
[as well as ascii bomb xlpoits and telling some poor slob that the way to defrag his HD was to use rm -rf / & >
[disclaimer: I did not do any of those things; but have seen the rm -rf message; and by the time that other responded "DONT DO THAT" it was too late]...
aahh... the good old days.... when time was abundant and free.....
--
Time is on my side
NOW linux is ready for the desktop
Manipulate the moderator system! Mod someone as "overrated" today.
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?
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.
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
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?
The people that you're after are the people you depend on. We cook your meals. We haul away your trash. We connect your calls. We drive your ambulances. We guard you while you sleep. Do not fuck with us.
:P)
(sorry, it just fits, in my psychotic mind.
It's been a long time.
Since when having a security problem became a required feature for desktop OS?
Oh... never mind!
Thanks for the reply
What do you know a frenchy posting as an Anonymous **COWARD** it just feels right..
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