[PATCH] UBUNTU: SAUCE: ptrace: restrict ptrace scope to children

Kees Cook kees at ubuntu.com
Thu May 13 08:33:36 UTC 2010


Hi Scott,

On Thu, May 13, 2010 at 10:13:27AM +0200, Scott James Remnant wrote:
> On Wed, 2010-05-12 at 15:22 -0700, Kees Cook wrote:
> 
> > As Linux grows in popularity, it will become a growing target for
> > malware. One particularly troubling weakness of the Linux process
> > interfaces is that a single user is able to examine the memory and
> > running state of any of their processes. For example, if one application
> > (e.g. Empathy) was compromised, it would be possible for an attacker to
> > attach to other processes (e.g. Firefox) to extract additional credentials
> > and continue to expand the scope of their attack.
> > 
> This is completely possible anyway, even with your patch.  I would do
> the following:
> 
>  - send SIGSTOP to the compositor to disable screen updates
> 
>  - send command to firefox to save browser state and exit
>    (or SIGKILL)
> 
>  - fork/exec firefox again (will reappear on the screen as it was
>    before)
> 
>  - firefox is now your child, ptrace
> 
>  - send SIGCONT to the compositor to resume screen updates
> 
> Firefox is now being ptraced, but the user never knows what happens.

This patch is specifically for blocking access to processes that hold
credentials in memory but don't set prctl[1].  This change pro-actively
helps protect such scenarios.

Firefox was just an example.  I could have just as well used other stuff
that doesn't save state as well.  I totally admit that trying to defend
the user from the user is a losing game, but I do feel that layered
defense is still worth it when it is both configurable and doesn't cause
problems for the general case.

> So your patch adds inconvenience for no additional security, thus I
> object to this.

Having developers/admins use sudo or add a file to /etc/sysctl.d to
restore the original PTRACE behavior isn't much of an inconvenience.

-Kees

[1] https://launchpad.net/bugs/572045

-- 
Kees Cook
Ubuntu Security Team




More information about the kernel-team mailing list