Vulnerability

    /dev/null

Affected

    Microport  Unix  3.0e  and  probably  other  versions of Microport
    Unix.

Description

    Any user  can execute  '386 I/O  instructions in  Microport's Unix
    3.0e. The  bug is  as fallows:  the /dev/mem  driver was  given an
    ioctl to do I/O instructions. (Examination of the source  suggests
    that this was done by Microport, in the modification, no check  on
    the minor device  number is made.   Since /dev/null uses  the same
    driver,  ioctls  on  /dev/null  can  also  do I/O instructions. To
    makeuse of  the bug,  one constructs  a program  to open /dev/null
    and do ioctls. This does  not require access to a  compiler; shell
    access  and  any  of  a  number  of  tools  are sufficient. Taking
    advantage of  this bug  permits any  number of  security problems:
    easiest  is  to  crash  the  system.  A  clever  hacker can almost
    certainly arrange  to get  a uid  0 process  with it. (Think about
    DMA'ing a zero into just the right byte of the process table.)

Solution

    This is a kernel bug and  there is no easy work-around for  binary
    only sites. The following should eliminate the bug, with some side
    effects:

        adb -w /unix
        mmioctl?W0c3

    *All*  memory  driver  ioctls  will  be  ignored  with this patch.
    Programs that  us the  memory driver  to do  I/O instructions will
    fail.  Also,  there  is  reboot  code  in  there  which  has  been
    superceded by the uadmin system call; I don't think anything  uses
    that. The biggest problem is that this same ioctl us used for  the
    limited runtime control; I have  no idea whether your system  will
    boot with this patch, /etc/init may well have a hissy fit when  it
    tries to do those ioctls. If you have source code, add

        if(minor(dev) == 2) {
            u.u_error = ENXIO;
            return;
        }

    to the top of mmioctl in mem.c. This will eliminate the bug.