[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