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

[Kees Cook]

On Thu, May 27, 2010 at 02:56:52PM +0200, Stefan Bader wrote:
> It seems the implementation itself is not so much questioned here than the
> resulting behaviour (beside I probably would name the variable ptrace_testricted
> to be clearer, though that is a bit nitpick).

My intention is to add two more additional scopes: root-only ("2"), and
init-only ("3").  This would offer the widest possible range of ptrace
security controls.  These two modes were not trivial (as I need to hook the
actual TRACEME methods too) so I didn't implement them for this early
version of the feature.

> >From the resulting behaviour itself I am probably less strongly biased. The
> inconvenience of running 'sudo strace -p#' I don't see as that bad. But on the
> other hand the security gain is maybe not worth the effort. What prevents
> malware from just adding a wrapper script to target applications while ptracing
> them as their parent?

The protection is for ephemeral credentials; it protects
authentication that happened in the past.  I have no illusions that
the trojan-horse-wrapper is unaffected by this protection, but that
is a slightly different form of attack (attacking authentications in
the future).  Currently there is nothing to prevent a process from
executing arbitrary code in an existing and already running process
owned by the same uid that hasn't been made undumpable.  In the case of
ssh or gpg-agent, this is rather bad.

As an example, an attacker can extend their reach to other systems
by opening new tunnels down existing connected ssh sessions (who did
their authentication in the past).  This is not a theoretical problem;
a tool to do this already exists[1].  Similarly, tools to do arbitrary
code injection via PTRACE exist[2], leaving the possibilities of abuse
wide open.  (I can imagine all sorts of things, jumping into running VNCs,
entering running VMs, manipulating logged-into websites, etc.)

In the case of a wrapper, the user would need to start new processes
before they could be further abused.  I view this as the difference
between a "user assisted/tricked" attack (where the victim must do
something) vs a full-blown automated worm attack (where the victim just
has to have things running).

> Could the goal be reached through extending apparmor to impose restrictions like
> that based on profiles? (maybe that already exists and I am just to be blamed
> for ignorance on it).

AppArmor (and in a similar fashion, SELinux) already restricts PTRACE
to the scope of the running profile, so things that are already confined
are okay as long as the process under confinement is attacker-controlled
(i.e. the scope of the attack against a confined process cannot be
extended with PTRACE -- but nothing stops an unconfined process from
PTRACEing a confined process).  This patch seeks to provide a global
solution to arbitrary PTRACEing, to gain a protection against abuse of
already-running processes.

-Kees

[1] http://www.storm.net.nz/projects/7
[2] http://c-skills.blogspot.com/2009/10/injectso-32bit-x86-port.html

-- 
Kees Cook
Ubuntu Security Team