[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
ptrace_scope now set to 0 by default
From: |
Ludovic Courtès |
Subject: |
ptrace_scope now set to 0 by default |
Date: |
Sun, 12 Apr 2015 15:49:55 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) |
While debugging an elfutils build failure, I discovered a Linux
restriction that I had been papering over using sudo for some time.
Starting from Linux 3.4 or so, the default policy is to disallow users
to attach (with PTRACE_ATTACH) to their own processes. Only
CAP_SYS_PTRACE processes (i.e., root) or the target process’ parents can
attach.
This is “for security reasons”, as noted in Linux’s Yama.txt:
ptrace_scope:
As Linux grows in popularity, it will become a larger 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. Pidgin) was compromised, it would be possible for an attacker to
attach to other running processes (e.g. Firefox, SSH sessions, GPG agent,
etc) to extract additional credentials and continue to expand the scope
of their attack without resorting to user-assisted phishing.
This is not a theoretical problem. SSH session hijacking
(http://www.storm.net.nz/projects/7) and arbitrary code injection
(http://c-skills.blogspot.com/2007/05/injectso.html) attacks already
exist and remain possible if ptrace is allowed to operate as before.
Since ptrace is not commonly used by non-developers and non-admins, system
builders should be allowed the option to disable this debugging system.
For a solution, some applications use prctl(PR_SET_DUMPABLE, ...) to
specifically disallow such ptrace attachment (e.g. ssh-agent), but many
do not. A more general solution is to only allow ptrace directly from a
parent to a child process (i.e. direct "gdb EXE" and "strace EXE" still
work), or with CAP_SYS_PTRACE (i.e. "gdb --pid=PID", and "strace -p PID"
still work as root).
But this sounds a little bit silly: it imposes a serious restriction on
what users can do (they can no longer attach gdb and such to their own
processes!) while providing dubious security improvements.
First, we’re talking about attackers who have a user shell anyway, so
one could argue that PTRACE_ATTACH is just one option among many, many
others the attacker could use. Second, the “right fix” is known:
security-sensitive applications such as agent can explicitly ask not be
to attachable.
There seem to be quite a few people on the intertubes who question this
security policy along these lines. See for instance:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712740
https://bugzilla.redhat.com/show_bug.cgi?id=1210966
So commit b158f1d restores the original PTRACE_ATTACH behavior by
default.
If you think this is wrong, let’s discuss it! :-)
Thanks,
Ludo’.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- ptrace_scope now set to 0 by default,
Ludovic Courtès <=