archive mirror
 help / color / mirror / Atom feed
From: Bernhard Kaindl <>
To:, Yusuf Wilajati Purna <>
	Bernhard Kaindl <>,
Subject: Re: 2.4+ptrace exploit fix breaks root's ability to strace
Date: Sat, 19 Apr 2003 07:57:35 +0200	[thread overview]
Message-ID: <Pine.LNX.4.53.0304190532520.1887@hase.a11.local> (raw)
In-Reply-To: <>

On Thu, 17 Apr 2003, Yusuf Wilajati Purna wrote:
> On 2003-03-22 17:28:54, Arjan van de Ven wrote:
> >On Sat, Mar 22, 2003 at 05:13:12PM +0000, Russell King wrote:
> >>
> >> int ptrace_check_attach(struct task_struct *child, int kill)
> >> {
> >> 	...
> >> +       if (!is_dumpable(child))
> >> +               return -EPERM;
> >> }
> >>
> >> So, we went from being able to ptrace daemons as root, to being able to
> >> attach daemons and then being unable to do anything with them, even if
> >> you're root (or have the CAP_SYS_PTRACE capability).  I think this
> >> behaviour is getting on for being described as "insane" 8) and is
> >> clearly wrong.
> >
> >ok it seems this check is too strong. It *has* to check
> >child->task_dumpable and return -EPERM, but child->mm->dumpable is not
> >needed.
> So, do you mean that the following is enough:
> int ptrace_check_attach(struct task_struct *child, int kill)
> {
>       ...
> +       if (!child->task_dumpable)
> +               return -EPERM;
> }

It's enough to still be safe against the ptrace/kmod exploits.

I could not find a security problem in it yet because
compute_cred() ignores the suid bit on exec when the
process is being traced, so the strace does not get
access to privileges from somebody else and ptrace_attach
uses is_dumpable() which also checks task->mm->dumpable
so a tracer can't attach to a suid program.

It will also help the case Russell King describes above
where root failed to trace a daemon which changed uids
or a suid program, AFAICS.

It is not the complete fix for it because the ptrace functions
also use access_process_vm() where the patch had this hunk:

@@ -123,6 +127,8 @@ int access_process_vm(struct task_struct
        /* Worry about races with exit() */
        mm = tsk->mm;
+       if (!is_dumpable(tsk) || (&init_mm == mm))
+               mm = NULL;
        if (mm)

You need to backout the tsk->mm->dumpable check done within is_dumpable
here by just checking task_dumpable and then ptracing from root works
prperly again.

As the kmod ptrace fix relies on task_dumpable for it's protection against
kernel thread trace, and you just remove the tsk->mm->dumpable check by
replacing !is_dumpable(tsk) with !tsk->task_dumpable here also, you don't
affect the kmod ptrace exploit protection in any way while fixing the
ability of root to trace any task.

This also fixes the problem /proc/<pid>/cmdline being empty (also for root)
if <pid> is not dumpable, which is the other bug introduced by this hunk
and broke process managment tools as it was also read on l-k.

Of course now people may say that this opens a security hole because a
normal user ist now able to read /proc/*/cmdline again (also for not
dumpable processes) but I'm answering to this that it has been well
known that it is insecure to put secrets onto the command line space
and e.g. if programs don't clear it properly, they are buggy and should
be audited to fix the bugs and not add a workaound to the kernel for
such programs.


  reply	other threads:[~2003-04-19  6:43 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-17  5:46 2.4+ptrace exploit fix breaks root's ability to strace Yusuf Wilajati Purna
2003-04-19  5:57 ` Bernhard Kaindl [this message]
2003-04-22  5:03   ` Yusuf Wilajati Purna
2003-04-22 22:30     ` [PATCH][2.4+ptrace] fix side effects of the kmod/ptrace secfix Bernhard Kaindl
2003-04-24  5:40       ` Nuno Silva
2003-04-24  9:00         ` Arjan van de Ven
2003-04-24 11:26           ` Bernhard Kaindl
  -- strict thread matches above, loose matches on Subject: below --
2003-03-22 10:31 2.4+ptrace exploit fix breaks root's ability to strace Russell King
2003-03-22 14:58 ` Alan Cox
2003-03-22 14:10   ` Russell King
2003-03-22 15:28     ` Arjan van de Ven
2003-03-22 17:13       ` Russell King
2003-03-22 17:28         ` Arjan van de Ven
2003-03-22 19:09         ` Alan Cox
2003-03-22 18:01           ` Russell King
2003-03-23 10:31   ` Lists (lst)
2003-03-23 10:38     ` Russell King
2003-03-23 11:11       ` Martin Loschwitz
2003-03-23 10:43     ` Arjan van de Ven

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.53.0304190532520.1887@hase.a11.local \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).