Bugtraq mailing list archives
Re: ipop3d (x2) / pine (x2) / Linux kernel (x2) / Midnight
From: okir () MONAD SWB DE (Olaf Kirch)
Date: Fri, 9 Apr 1999 10:48:05 +0200
--qDbXVdCdHGoSgWSk Content-Type: text/plain; charset=us-ascii -------- 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 okir () monad swb de | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax --qDbXVdCdHGoSgWSk Content-Type: application/x-patch Content-Disposition: attachment; filename="imap-4.4.patch" 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; } --qDbXVdCdHGoSgWSk--
Current thread:
- Re: ipop3d (x2) / pine (x2) / Linux kernel (x2) / Midnight Mark Crispin (Apr 08)
- Re: ipop3d (x2) / pine (x2) / Linux kernel (x2) / Midnight Olaf Kirch (Apr 09)
- Re: ipop3d (x2) / pine (x2) / Linux kernel (x2) / Midnight Mark Crispin (Apr 09)
- Re: ipop3d (x2) / pine (x2) / ... GvS (Apr 11)
- Re: ipop3d (x2) / pine (x2) / ... Thomas Roessler (Apr 12)
- [support_feedback () us-support external hp com: Security Bulletins Patrick Oonk (Apr 13)
- Re: ipop3d (x2) / pine (x2) / Linux kernel (x2) / Midnight Mark Crispin (Apr 09)
- Re: ipop3d (x2) / pine (x2) / Linux kernel (x2) / Midnight Olaf Kirch (Apr 09)
- Patrol security bugs fcosta (Apr 09)
- Re: ipop3d (x2) / pine (x2) / Linux kernel (x2) / Midnight M.C.Mar (Apr 09)
- New Novell Remote.NLM Password Decryption Algorithm with Exploit dreamer () RELIA NET (Apr 09)
- Novell Pandora Hack Jeremy M. Guthrie (Apr 12)
- Re: Novell Pandora Hack Simple Nomad (Apr 13)
- Re: Novell Pandora Hack Iain P.C. Moffat (Apr 13)
- New Novell Remote.NLM Password Decryption Algorithm with Exploit dreamer () RELIA NET (Apr 09)