login
Search
With today's release of Linux kernel version 2.2.25, Alan Cox [interview] announced a vulnerability in the ptrace() system call that affects both the 2.2 and 2.4 stable kernels. The earlier 2.2.24 kernel was released a couple of weeks ago, with today's 2.2.25 release adding only the fix for this ptrace vulnerability. Alan explains:
"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."
When asked whether or not a new 2.4 kernel would be forthcoming as well, Alan suggested, "If you build your own kernels apply the patch, if you use vendor kernels then you can expect vendor kernel updates to appear or have already appeared". Read on for Alan's complete announcement, as well as a patch that fixes the problem in the 2.4 kernel.
From: Alan Cox Subject: Ptrace hole / Linux 2.2.25 Date: Mon, 17 Mar 2003 11:04:35 -0500 (EST) 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 [patch]
From: Arjan van de Ven Subject: Re: Ptrace hole / Linux 2.2.25 Date: 17 Mar 2003 18:57:21 +0100 On Mon, 2003-03-17 at 17:04, Alan Cox wrote: > 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. I've attached a patch against 2.4.21pre5
From: Tomas Szepe Subject: re: Ptrace hole / Linux 2.2.25 Date: Mon, 17 Mar 2003 19:20:40 +0100 > [arjanv] > > I've attached a patch against 2.4.21pre5. So what happens now? Is this critical enough for 2.4.21 to go out? Or can it wait like some other fairly serious stuff such as the ext3 fixes? What about the current state of IDE? Would it make sense to repackage 2.4.20 into something like 2.4.20-p1 or 2.4.20.1 with only the critical stuff applied? -- Tomas Szepe
From: Alan Cox Subject: re: Ptrace hole / Linux 2.2.25 Date: 17 Mar 2003 19:34:32 +0000 On Mon, 2003-03-17 at 18:20, Tomas Szepe wrote: > Is this critical enough for 2.4.21 to go out? Or can it wait like > some other fairly serious stuff such as the ext3 fixes? What about > the current state of IDE? > > Would it make sense to repackage 2.4.20 into something like 2.4.20-p1 > or 2.4.20.1 with only the critical stuff applied? If you build your own kernels apply the patch, if you use vendor kernels then you can expect vendor kernel updates to appear or have already appeared
Clean ptrace patch for 2.4.20
There is a clean patch for 2.4.20 (taken from Alans original patch) at http://www.hardrock.org/kernel/2.4.20/linux-2.4.20-ptrace.patch
I am currently using it on 3 production systems at work and it seems stable. You will notice processes which are not dumpable with this patch, as the output from ps ax will contain the process name in [] square brackets.
Regards
James Bourne
it patches cleanly, however i
it patches cleanly, however it doesn't compile, fails early in make dep.
An exploit
An exploit can be found at
http://isec.pl/cliph/isec-ptrace-kmod-exploit.c.
It claims the author found it before Red Hat did, works for me on 2.4.20, haven't had time to apply a patch yet to check that.
hmm so the -ac patches to 2.4
hmm so the -ac patches to 2.4.20 and 2.4.21pre obviously don't work:
[quel@quel ~/code/exploits/ptrace] ./a.out
[root@quel ~/code/exploits/ptrace]
that's my "patched 2.4.20 kernel"
back to the drawing board alan
It works...
You probably ran the exploit once before you tried it with your patched kernel, and the exploit binary was still setuid root. Try chowning the exploit binary back to non-root and running it then.
I made the same mistake when I tried it after I patched my kernel.
heh you're right :)
heh you're right :)
Grey Security?
$tewmten uname -rv
2.4.20-grsec #2 Thu Mar 13 18:48:26 CET 2003
$tewmten ./ptrace-sploit
[-] Fatal error: Unknown error 125
Killed
I tried that one, didn't work, is it cos I'm using grsec?
I couldn't patch the kernel either, it says it didn't know what file to patch.. maybe I did something wrong, I'm not sure.
What about the 2.0 kernels?
What about the 2.0 kernels? Are they vulnerable or are they okay? I still have two machines running 2.0.x kernels.
forget about the patch..!!!
hey!!
forget about the patch... dont you think you should first consider upgrading !? your system ?
One could agree that "if it aint broke, dont fix it..." is a golden rule, but still ....!!
rbs
No.
No, I have no interest in upgrading. 2.0.34 works fine for me right now on those machines. There's absolutly nothing to be gained from a newer kernel. Upgrading to something completely different is only asking for trouble. They sit in a rack and have been doing their job for several years now, only needing intervention when there is a security patch to be applied. Besides, the 2.0 kernel is still being maintained.
why not ?
I think that there is a HUGE performance and security gain in upgrading to 2.2 (or even better to 2.4), since there is a lot of "fix race condition in ..." in 2.2 and 2.4 chagelogs and I don't think that they are all backported to 2.0.x. Also performance and stability are better with 2.2 and 2.4.
I understand that you may want to keep your kernel since it work well, but if security is really important for you (for example, if you run a corporate server), you should seriously think about upgrading. If you only run theses computer at home or if you trust your users, there is no real need to upgrade since it is only a local hole.
rofl
> I think that there is a HUGE performance and security gain in
> upgrading to 2.2 (or even better to 2.4)
Ha ha, thanks for this one.
...advising someone to upgrade to 2.4 for a security gain.
why not also take the time to bragg about the stability and
quality of 2.4 kernels?
I'd stick with a real Cox kernel if I were youse.
Ciaran O'Riordan
Is 2.0 vulnerable?
I would like to know the answer to this as well. I do web hosting for a bunch of friends (who have shells) and the machine runs 2.0. The hardware simply can *NOT* be upgraded (for one, I have no physical access, second, the hardware is ancient and I don't know if a 2.x>0 kernel would work, I don't have the time).
Can anybody answer the question? (Not having 2.0 kernel sources handy at the moment)
Thanks.
Try running the exploit. [nt]
(placeholder text)
and the exploit is...
http://v-lo.krakow.pl/~anszom/km3.c
:>
don't want
i don't want to update, i have nearly 100 days uptime :-(
ist there no workaround?
kuse
workaround
With
echo /just/a/temporary/workaround > /proc/sys/kernel/modprobe
you can turn off module loading.
Note, that this might disable some services depending on your system and your usage.
works for 2.4.20, don't work for 2.5.65
Thank you!
I read that on /. too, tried it on my box running 2.5.65, without success.
But for 2.4.20, it works!
--
kuse