lkml.org 
[lkml]   [2012]   [Jan]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: Compat 32-bit syscall entry from 64-bit task!? [was: Re: [RFC,PATCH 1/2] seccomp_filters: system call filtering using BPF]
    From
    On Wed, Jan 18, 2012 at 4:14 PM, Indan Zupancic <indan@nul.nu> wrote:
    > On Wed, January 18, 2012 22:13, Chris Evans wrote:
    >> On Wed, Jan 18, 2012 at 4:12 AM, Indan Zupancic <indan@nul.nu> wrote:
    >>> On Wed, January 18, 2012 06:43, Chris Evans wrote:
    >>>> 2) Tracee traps
    >>>> 2b) Tracee could take a SIGKILL here
    >>>> 3) Tracer looks at registers; bad syscall
    >>>> 3b) Or tracee could take a SIGKILL here
    >>>> 4) The only way to stop the bad syscall from executing is to rewrite
    >>>> orig_eax (PTRACE_CONT + SIGKILL only kills the process after the
    >>>> syscall has finished)
    >>>
    >>> Yes, we rewrite it to -1.
    >>>
    >>>> 5) Disaster: the tracee took a SIGKILL so any attempt to address it by
    >>>> pid (such as PTRACE_SETREGS) fails.
    >>>
    >>> I assume that if a task can execute system calls and we get ptrace events
    >>> for that, that we can do other ptrace operations too. Are you saying that
    >>> the kernel has this ptrace gap between SIGKILL and task exit where ptrace
    >>> doesn't work but the task continues executing system calls? That would be
    >>> a huge bug, but it seems very unlikely too, as the task is stopped and
    >>> shouldn't be able to disappear till it is continued by the tracer.
    >>>
    >>> I mean, really? That would be stupid.
    >
    > Okay, I tested this scenario and you're right, we're screwed.
    >
    > What the hell guys?

    Steady on :) ptrace() has never been sold as a technology upon which
    its safe to build security solutions.

    > What about other PID checks in the kernel, are they still
    > safe if the process looks dead but is still active? Or is it a ptrace-only
    > problem?
    >
    >>> If true we have to work around it by disallowing SIGKILL and just sending
    >>> them ourselves within the jail. Meh.
    >
    > I guess this helps a bit. It doesn't prevent external signals, but prisoners
    > don't have control over that.

    Well.... a prisoner may be able to play other tricks:
    - Allocate lots of memory... kernel may start spraying around SIGKILLs
    - Sending SIGKILL via prctl()
    - Sending SIGKILL via fcntl()
    - Sending SIGKILL via clone()

    >
    > Is this SIGKILL specific or is it true for all task ending signals?

    Can't remember - try it?

    >
    >>> How will you avoid file path races with BPF?
    >>
    >> There is typically no need for file-path based access control in an FTP server.
    >> Take for example anonymous FTP, which will typically be inside a
    >> chroot() to /var/ftp. Inside that filesystem tree -- if you can open()
    >> it, you can have it.
    >
    > Ah, you count on having root access. We don't.
    >
    > Do you know any more crazy security destroying holes?

    Try spraying SIGCONT and / or SIGSTOP at tracees. It may be possible
    to confuse the tracer about whether a SIGTRAP event is syscall entry
    or exit.
    Try doing an execve() that fails. May cause similar state confusion in
    the tracer.


    Cheers
    Chris

    >
    > Thanks,
    >
    > Indan
    >
    >


    \
     
     \ /
      Last update: 2012-01-19 09:19    [W:4.185 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site