History

ptrace: Fix ->ptracer_cred handling for PTRACE_TRACEME

Fix two issues: When called for PTRACE_TRACEME, ptrace_link() would obtain an RCU reference to the parent's objective credentials, then give that pointer to get_cred(). However, the object lifetime rules for things like struct cred do not permit unconditionally turning an RCU reference into a stable reference. PTRACE_TRACEME records the parent's credentials as if the parent was acting as the subject, but that's not the case. If a malicious unprivileged child uses PTRACE_TRACEME and the parent is privileged, and at a later point, the parent process becomes attacker-controlled (because it drops privileges and calls execve()), the attacker ends up with control over two processes with a privileged ptrace relationship, which can be abused to ptrace a suid binary and obtain root privileges. Fix both of these by always recording the credentials of the process that is requesting the creation of the ptrace relationship: current_cred() can't change under us, and current is the proper subject for access control. This change is theoretically userspace-visible, but I am not aware of any code that it will actually break.

Jann Horn committed 7 years ago

Commit 6994eef1 parent 550d1f51 file · +1 −3Browse files

Showing the changes to kernel (1 of 1 file). Show all

Unified · Split

kernel/ptrace.c+1−3
@@ -79,9 +79,7 @@ void __ptrace_link(struct task_struct *child, struct task_struct *new_parent, · 78 unmodified lines
79 */79 */
80static void ptrace_link(struct task_struct *child, struct task_struct *new_parent)80static void ptrace_link(struct task_struct *child, struct task_struct *new_parent)
81{81{
82 rcu_read_lock();82 __ptrace_link(child, new_parent, current_cred());
83 __ptrace_link(child, new_parent, __task_cred(new_parent));
84 rcu_read_unlock();
85}83}
86 84
87/**85/**