Vulnerability

    VFS

Affected

    OpenBSD

Description

    Alexander Viro  found following.   Let's start  with the  trivial:
    good old aliasing bugs.

    Example 1:

        dup2() vs. close(). Relevant file: kern/kern_descrip.c
        
        sys_dup2(p, v, retval)
                struct proc *p;
                void *v;
                register_t *retval;
        {
        [snip]
                if ((u_int)old >= fdp->fd_nfiles || fdp->fd_ofiles[old] == NULL ||
                    (u_int)new >= p->p_rlimit[RLIMIT_NOFILE].rlim_cur ||
                    (u_int)new >= maxfiles)
                        return (EBADF);

    OK, we've checked (among other things) that old is indeed opened.

        [snip]
                if (new >= fdp->fd_nfiles) {

    We either expand a descriptor table

        [snip]
                } else {

    Or reuse existing descriptor, closing file if it's opened.

                        (void) fdrelease(p, new);

    Which is the blocking operation, BTW.

                }
                return (finishdup(fdp, old, new, retval));
        }
        [snip]
        finishdup(fdp, old, new, retval)
                register struct filedesc *fdp;
                register int old, new;
                register_t *retval;
        {
                register struct file *fp;
        
                fp = fdp->fd_ofiles[old];

    Got the struct sile of the file we are trying to dup...

                if (fp->f_count == LONG_MAX-2)

    ... and dereference it. We had checked that it's non-NULL, right?

    Wrong.  Another thread might be sharing our descriptor table  (man
    rfork).  IOW, fdp points to shared data structure.  So we had done
    the equivalent of

	        if (global_var) {
		        blocking_call();
		        if (global_var->f_count)
			        ...
	        }

    We have a  nice shiny race  between dup2(0,1); and  close(0).  And
    it's a wide one.  Turning that into full-blown exploit is left  as
    an exercise for readers.

    Example 2:

        pipe() vs. close() (kern/sys_pipe.c)
        
        sys_opipe(p, v, retval)
        [snip]
                error = falloc(p, &rf, &fd);
                if (error)
                        goto free2;
        [snip]
                retval[0] = fd;
        
                error = falloc(p, &wf, &fd);
                if (error)
                        goto free3;
        [snip]
                return (0);
        free3:
                ffree(rf);
                fdremove(fdp, retval[0]);
        free2:
        [snip]

    Think  what  happens  if  the  second  allocation  fails.  It is a
    blocking  call.   During  that  time  another  thread  had  a nice
    possibility to  call close(retval[0]);  since that  value is  very
    easy  to  predict  -  it's  the  first  available file descriptor.
    close() would
        * remove pointer from fdp[retval[0]]
        * call ffree() on it.

    Now, we  come back  and do  _another_ ffree()  on the  poor beast.
    Welcome to kernel panic...  Code is equivalent to

        global_var = p = alloc_foo();
        blocking_call();
        release_foo(p);
        global_var = NULL;

    It's obviously broken - obviously for anyone with half of clue.

    One can easily provide more examples  of the same crap and so  can
    anyone who would bother to RTFS the descriptor handling in kern/*.
    Apparently that had never happened during the last 5 years or so.

    Not talking about the bugs that would require anything  nontrivial
    to find and understand.  Just follow the yello^Wpiles of sloppy  C
    and nearly every  one will turn  out to be  exploitable.  And  no,
    it's  not  limited  to  descriptor   handling  -  same  goes   for
    sys_pipe.c, etc.

Solution

    Nothing yet.