# Local Root Hole - Current gentoo-sources vulnerable

## ViCToR:

I read on Slashdot this : article

 *Quote:*   

> 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."

 

Tried this exploit: http://isec.pl/cliph/isec-ptrace-kmod-exploit.c

And ...

```
myuser@myhost exploit $ uname -a

Linux myhost.host.org 2.4.20-gentoo-r1 #1 Fri Feb 28 13:46:23 CET 2003 i686 AMD Athlon(tm) Processor AuthenticAMD GNU/Linux

myuser@myhost exploit $ ./isec-ptrace-kmod-exploit 

[+] Attached to 7946

[+] Signal caught

[+] Shellcode placed at 0x4000ef1d

[+] Now wait for suid shell...

sh-2.05b# id

uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy), 20(dialout),26(tape),27(video)
```

Vulnerable kernels: 2.2.x x<25 and 2.4.y y<21

As you can see, I have latest 2.4.20-gentoo-r1 kernel running and ... ugh it works.

I also read kernels with grsecurity patch are NOT vulnerable. I haven't tested it yet.

Let's hope for a quick patch   :Neutral: 

EDIT:  Added a space after a comma on the "groups" line for word wrapping.  -- pjp

----------

## splooge

It's patched in 2.4.20-gentoo-r2

----------

## ViCToR:

Yes, true:

```
# ChangeLog for sys-kernel/gentoo-sources

# Copyright 2002-2003 Gentoo Technologies, Inc.; Distributed under the GPL v2

# $Header: /home/cvsroot/gentoo-x86/sys-kernel/gentoo-sources/ChangeLog,v 1.19 2003/03/19 06:14:24 pfeifer Exp $

*gentoo-sources-2.4.20-r2 (19 Mar 2003)

  19 Mar 2003; Jay Pfeifer <pfeifer@gentoo.org> gentoo-sources-2.4.20-r2.ebuild:

  Package is currently marked unstable.

  * Added ptrace security fix.    <----- PATCH

...
```

Still marked as unstable though  :Sad: 

----------

## splooge

 *ViCToR: wrote:*   

> I read on Slashdot this : article
> 
>  *Quote:*   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." 
> 
> Let's hope for a quick patch  

 

----------

## ViCToR:

yeah I know. I meant a patch for the gentoo-sources. The patch from Andrzej Szombierski cannot be applied to gentoo-sources since it fails.

----------

## frogger

It does seem that grsecurity patched kernels are not vulnerable.  I am running a grsec patched vanilla 2.4.20 kernel, and attempting to run this exploit gave me only

[-] Fatal error: Operation canceled

Killed

as output.  No root shells.  So I guess that's good news  :Smile: 

----------

## dioxmat

what about the other kernels, i.e. gaming-sources, ck-sources ?

----------

## humpback

Some things to be carefull:

1- gentoo-sources-2.4.20-r2 does not include XFS.

2- People running grsec kernels may or may not be protected (i have gentoo-sources-2.4.19-r10 and the exploit just eats cpu and does nothing).

3- The lates XFS sources are patched.

4- gaming and ck sources at the time of this post are PROBABLY unpatched. The last entry on the changelog is before the exploit came out.

I have talked to livewire (the xfs-sources maintiner) about grsec in xfs, and he told be a release would come out probably before saturday.

The exploit is only local.. So if no one has shell acess to your machine they cannot do nothing.

----------

## ebrostig

Ck-sources is vulnerable.

```

uname -r

2.4.20-ck4

ebrostig@dhcp-orlando3-*****-43 ebrostig $ ./isec

root@dhcp-orlando3-*****-43 ebrostig #

```

Needs a patch.

Erik

----------

## doubt

XFS sources marked as stable .20-xfs-pre6 are vulnerable.  I was able to get the patch to install with just one modification ( looking at the .reject files was obvious how to adjust).

.Doubt

----------

## ViCToR:

 *Quote:*   

> - - ---------------------------------------------------------------------
> 
> GENTOO LINUX SECURITY ANNOUNCEMENT 200303-17
> 
> - - ---------------------------------------------------------------------
> ...

 

Here we are  :Smile:  Gentoo as fast as always.

And some people still wonder why it's te best distro   :Laughing: 

Thanks, and keep up the good work!

----------

## Reverent

The binary of the exploit still works with gentoo-sources-r2 !

i compiled the exploit on gentoo-sources 2.4.20-r1 and it worked. I installed the 2.4.20-r2, when i compile the exploit now and run it i get a Operation nor permitted. But i kept the old binary of the exploit i compiled with the gentoo-source-r1 and i can get root with it on the r2 !

So i just copy the binary compiled with the r1 on another machine and can exploit even when there's a patched kernel running ???

```

packetstorm% ls

exploit  exploit.old  isec-ptrace-kmod-exploit.c

packetstorm% id

uid=1001(payne) gid=10(wheel) groups=10(wheel)

packetstorm% ./exploit

[-] Unable to attach: Operation not permitted

zsh: killed     ./exploit

packetstorm% ./exploit.old

sh-2.05b# id

uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy), 20(dialout),26(tape),27(video)

sh-2.05b#

```

EDIT:  Added a space after a comma on the "groups" line for word wrapping.  -- pjp

----------

## swimmer

Hi all, 

the gaming-sources are vulnerable - I got the patch from http://cvs.gentoo.org/~aliz/linux-2.4.20-ptrace.patch

See also this thread

Greetz

Stefan

----------

## humpback

 *Reverent wrote:*   

> The binary of the exploit still works with gentoo-sources-r2 !
> 
> i compiled the exploit on gentoo-sources 2.4.20-r1 and it worked. I installed the 2.4.20-r2, when i compile the exploit now and run it i get a Operation nor permitted. But i kept the old binary of the exploit i compiled with the gentoo-source-r1 and i can get root with it on the r2 !
> 
> So i just copy the binary compiled with the r1 on another machine and can exploit even when there's a patched kernel running ???
> ...

 

After a successefull run the exploit sets itself suid, so it will run on a patched kernel. if you as a normal user try to copy files suid between hosts the suid bit is droped.

So after patching your kernel do a search in your servers for suid programs.

----------

## tyreth

 *humpback wrote:*   

> 
> 
> So after patching your kernel do a search in your servers for suid programs.

 

How does one do that?

----------

## dma

I've already patched my gentoo-sources-2.4.20-r1 with the ptrace fix.  I'm holding off on -r2 because I require XFS.  (And no I won't use xfs-sources because I am too lazy to add the grsecurity patches and the other stuff.)  I've gotten accustomed to ACLs with OpenAFS and I need them for some stuff.

I don't have kernel preemption enabled and I don't use JFS so XFS will probably work OK.

I'd personally like to see them add the XFS use flag support back in (as would many people I'm sure).  I was quite happy when I discovered that undocumented little gem.

----------

## miez

Hi,

it's nice to have a patched kernel, but i have some production

machines out in the net which can't be rebooted easily..

Here is a dirty hack to disable the vulnerability at runtime.

```

#!/bin/sh

# initscript to circumvent the ptrace vulnerability

# (C) 2003 LISA systems oHG Hamburg, Germany

# Author J. Kruegel <sixpack@lisa.de>

#

#set -x

ME="${0##*/}"

PROCFILE="/proc/sys/kernel/modprobe"

# check for distribution inconvenience

# old suse

if [ -d /sbin/init.d ] && [ -d /sbin/init.d/rc2.d ]; then

        initdir=/sbin/init.d

        rcdir=/sbin/init.d

# new suse

elif [ -d /etc/init.d ] && [ -d /etc/init.d/rc2.d ]; then

                initdir=/etc/init.d

                rcdir=/etc/init.d

# old redhat & debian woody

elif [ -d /etc/init.d ] && [ -d /etc/rc2.d ]; then

                initdir=/etc/init.d

                rcdir=/etc

# new redhat

elif [ -d /etc/rc.d/init.d ] && [ -d /etc/rc.d/rc2.d ]; then

        initdir=/etc/rc.d/init.d

        rcdir=/etc/rc.d

# there may be some gentoo systems out there..

elif [ -f /etc/gentoo-release ]; then

        initdir=/etc/init.d

        rcdir=nosuchdir

        echo "$ME: warning: setup disabled for gentoo systems.."

else

#       left here as a reminder..

        echo "could not determine init.d directory.." >&2

        echo "please setup by hand" >&2

#       exit 1

fi

case $1 in

        start)  echo "/sbin/foo" > ${PROCFILE} ;;

        stop)   echo "/sbin/modprobe" > ${PROCFILE} ;;

        status)

                if $(cat ${PROCFILE} | \

                        grep modprobe >/dev/null 2>&1); then

                                echo "ptrace exploit seems to be possible" >&2

                else

                        echo "ptrace exploit disabled" >&2

                fi

        ;;

        setup)

                if [ -d ${initdir} ] && [ -d ${rcdir} ]; then

                cd $initdir

                        for i in 2 3 4 5; do

                                ln -s ${initdir}/${ME} ${rcdir}/rc${i}.d/S99${ME}

                                ln -s ${initdir}/${ME} ${rcdir}/rc${i}.d/K01${ME}

                        done

                else

                        echo "could not determine init.d or rc.d directory either.." >&2

                        echo "please setup by hand" >&2

                        exit 1

                fi

        ;;

        delete)

                if [ -d ${rcdir} ]; then

                        for i in 2 3 4 5; do

                                rm -f ${rcdir}/rc${i}.d/[SK]??${ME}

                        done

                else

                        echo "could not determine rc.d directory.." >&2

                        echo "please remove start and stop links by hand" >&2

                        exit 1

                fi

        ;;

        *)

                echo "USAGE: $ME [start|stop|status|setup|delete]" >&2

        ;;

esac

# vim:ts=4

```

copy it to the init.d directory (name it as you like) and

chmod 0700 it.

The rc directory links shall ensure tha it's last script run at

bootup for it disables automatic module loading if the other

initscripts don't do it with modprobe explicitely.

          regards, miez

----------

## KraziKid

If I use the patch provided to patch my kernel, do I need to reboot?

----------

## miez

Hi KraziKid,

 the patch works on the (basic) kernel not just on a certain

module you can install and reload.

The only way to reload the kernel is to reboot. This is rare

situation you _must_ reboot your linux system.

     regards, miez

--

a lli'l ad:

UNHAPPY!??

When you're dead you'll grin all day!

- these words where stolen for an old record of

   welsh poet Pete Brown

----------

## bone

It looks to not work against a few grsecurity patched kernels:

[legion@gk:legion] gcc -o isec isec-ptrace-kmod-exploit.c

[legion@gk:legion] id

uid=1002(legion) gid=100(users) groups=100(users)

[legion@gk:legion] ./isec

[-] Fatal error: Operation canceled

Killed

[legion@gk:legion] id

uid=1002(legion) gid=100(users) groups=100(users)

[legion@gk:legion] uname -a

Linux gk.bone.ath.cx 2.4.19-gentoo-r10 #1 Wed Jan 1 21:15:37 CST 2003 i686 AMD Duron(tm) Processor AuthenticAMD GNU/Linux

[legion@gk:legion]

----------

## dioxmat

fwiw, its still an issue with ck6...

I dont have acces to my bugzilla email adress at work. can anyone file it ?

----------

## pjp

I could be mistaken, but I'm guessing the announcement in News & Announcements will cover that.  That is, patching other kernels manually.

Or did you mean file a bug for ck sources people?

----------

## dioxmat

I meant file a bug for ck sources people yes. (but an announcement telling users to patch manually wouldnt be a bad idea...)

----------

