Re: How to fix the ptrace flaw without rebooting

Re: How to fix the ptrace flaw without rebooting

[Chuck Ebbert]

Erik Hensema wrote:


> A better fix in a running system is to simply disable dynamic module
> loading: echo /no/such/file > /proc/sys/kernel/modprobe


 You mean like this?

   # echo 'x'>/proc/sys/kernel/modprobe
   bash: /proc/sys/kernel/modprobe: No such file or directory

:)

--
 Chuck

Re: How to fix the ptrace flaw without rebooting

[Alan Cox]

On Gwe, 2003-04-04 at 12:18, Chuck Ebbert wrote:
> Erik Hensema wrote:
> 
> 
> > A better fix in a running system is to simply disable dynamic module
> > loading: echo /no/such/file > /proc/sys/kernel/modprobe
> 
> 
>  You mean like this?
> 
>    # echo 'x'>/proc/sys/kernel/modprobe
>    bash: /proc/sys/kernel/modprobe: No such file or directory

Thats not a sufficient fix except for people blindly running the
example exploit

[2.4] ptrace bugfix breaks strace and keeps processes in STOPPED state (was: Re: How to fix the ptrace flaw without rebooting)

[Henning P. Schmiedehausen]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

>On Gwe, 2003-04-04 at 12:18, Chuck Ebbert wrote:
>> Erik Hensema wrote:
>> 
>> 
>> > A better fix in a running system is to simply disable dynamic module
>> > loading: echo /no/such/file > /proc/sys/kernel/modprobe
>> 
>> 
>>  You mean like this?
>> 
>>    # echo 'x'>/proc/sys/kernel/modprobe
>>    bash: /proc/sys/kernel/modprobe: No such file or directory

>Thats not a sufficient fix except for people blindly running the
>example exploit

Speaking of the exploit fix: Since I run a kernel which has it
installed, I can no longer strace processes which do run as root but
have a gid sbit set, e.g.

# ls -la /tmp/bash 
-rwxr-sr-x    1 root     smmsp      541096 Apr  5 10:21 /tmp/bash
# id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)
# /tmp/bash
bash-2.05a# echo $$
2625

(in another shell)

# strace -f -p 2625
trace: ptrace(PTRACE_SYSCALL, ...): Operation not permitted
detach: ptrace(PTRACE_DETACH, ...): Operation not permitted

but the shell with the pid of 2625 is now "dead" until one sends it a 
SIGCONT:

# kill -CONT 2625

(other shell now works again)

% uname -an
Linux henning-pc 2.4.18-27.7.x #1 Fri Mar 14 06:44:53 EST 2003 i686 unknown

I'm running the most current strace (4.4.94) because of the STOP/CONT
problems before (RH bugzilla #64303, #75709) but this is new after
installing the exploit fix.

(I found this BTW trying to trace sendmail that's why I have that test
case with setgid to smmsp).

	Regards
		Henning

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen          INTERMETA GmbH
hps@intermeta.de        +49 9131 50 654 0   http://www.intermeta.de/

Java, perl, Solaris, Linux, xSP Consulting, Web Services 
freelance consultant -- Jakarta Turbine Development  -- hero for hire

Re: How to fix the ptrace flaw without rebooting

[Paul Jakma]

On 4 Apr 2003, Alan Cox wrote:

> Thats not a sufficient fix except for people blindly running the
> example exploit

Also, removing CAP_SYS_PTRACE from the capability bounded set does
not close the hole (well, as shown by the exploit) either. It seems
CAP_SYS_PTRACE only closes the case of PTRACE_ATTACH, all other
ptrace()'s work, eg PTRACE_TRACEME -> strace echo foo and the exploit 
works too.

Should CAP_SYS_PTRACE not do as the name suggests and completely 
disallow ptrace()? (not just PTRACE_ATTACH).

regards,
-- 
Paul Jakma	paul@clubi.ie	paul@jakma.org	Key ID: 64A2FF6A
	warning: do not ever send email to spam@dishone.st
Fortune:
An egghead is one who stands firmly on both feet, in mid-air, on both
sides of an issue.
		-- Homer Ferguson