Date: Sun, 28 Jun 1998 00:02:56 -0400
Reply-To: Bugtraq List
Sender: Bugtraq List
From: Automatic digest processor
Subject: BUGTRAQ Digest - 26 Jun 1998 to 27 Jun 1998
To: Recipients of BUGTRAQ digests
Message-Id: <19980628040511Z96035-4990+11@brimstone.netspace.org>
There are 19 messages totalling 1154 lines in this issue.
Topics of the day:
1. !!! FLASH TRAFFIC !!! QPOPPER REMOTE ROOT EXPLOIT (3)
2. Bug is sudo?
3. Vulnerability in 4.4BSD Secure Levels Implementation
4. check-ps 1.2 alpha 4 released
5. {proc,kern}fs bug in FreeBSD (other systems?)
6. vulnerability in satan, cops & tiger
7. QPOPPER problem.... ONE crude patch... (3)
8. patch for qpopper remote exploit bug (2)
9. NetBSD Security Advisory 1998-004: at(1) vulnerabilities.
10. (FWD) QPOPPER REMOTE ROOT EXPLOIT
11. QPOPPER problem.... (3)
12. More patch ideas for qpopper
----------------------------------------------------------------------
Date: Sat, 27 Jun 1998 00:58:24 -0400
From: Seth McGann
Subject: !!! FLASH TRAFFIC !!! QPOPPER REMOTE ROOT EXPLOIT
Its come to my attention that systems around the internet are being
exploited using a new remote overflow in Qualcomm's Popper server. Well,
lets clear a few things up:
1. The working exploit was stolen from my development account,
subsequently MANY sites were cracked in short order. Much of Efnet was
compromised as power crazed script kiddies gained root access on IRCOP
boxes, giving themselves O-lines.
2. This vulnerability effects FreeBSD, OpenBSD, and Solaris x86 so far.
Other systems are most certainly vulnerable. Linux does not appear
vulnerable. To test, simply send the sever several thousand characters and
see if it crashed. Check the return address to see if it matches.
3. Due to massive exploitation the proper authorities have most likely
been notified already. This is a bit of an emergency.
4. You will NOT get the "exploit" from me, don't ask. If you think your
"eleet" enough, do it yourself. I admit I had some help, but it took a
while to figure out.
5. The most obvious offender is the vsprintf() on line 66 of pop_msg.c.
6. If you have a problem with my style, I'm sorry. I'm angry at both
myself and the members of #conflict who I hold directly responsible for
this breach. I will not name names, the offenders know who they are.
7. When I have my head together I will post a patch tomorrow if one is not
available by then.
8. For now, disable qpopper or choose another solution till qpopper is
secured.
Thank you.
Seth M. McGann / smm@wpi.edu "Security is making it
http://www.wpi.edu/~smm to the bathroom in time."
KeyID: 2048/1024/E2501C80
Fingerprint 3344 DFA2 8E4A 977B 63A7 19E3 6AF7 4AE7 E250 1C80
------------------------------
Date: Fri, 26 Jun 1998 23:17:54 -0600
From: Warner Losh
Subject: Re: Bug is sudo?
In message Rhodie writes:
: I was messing arround with sudo when i found out that you can check to see
: if there is a file that can be exec'd by root, even if you don't have the
: privlages. IE: You can check to see if there is a program, in the root
: path, that you can't see (maybe can and its just easyer to do it this
: way).
Not quite. Sudo uses the current value of $PATH to determine where to
run a program or not. Root's "path" isn't even consulted.
: So? you say, well, you can check to see if there is something to play with
: that root has hidden....
You can use this to find out if there are files of a given name in
directories that you cannot otherwise ls. You still cannot actually
execute them, and if you guess right, mail goes to root.
So this isn't a huge deal, but it is a leak in information.
BTW, did you send this to the sudo list before broadcasting it to
bugtraq to give Todd Miller a change to fix it or at least reply to
you? He's very good about investigating potential problems with sudo
and something like this I'd imagine he'd be keen on fixing ASAP.
Warner
------------------------------
Date: Fri, 26 Jun 1998 08:41:01 -1000
From: Tim Newsham
Subject: Re: Vulnerability in 4.4BSD Secure Levels Implementation
> Not propagating the immutable filesystem flag on an executable to its
> address space, as you suggest is the correct and documented behaviour,
> implies the following:
>
> - The syslogd daemon can be covertly compromised, so no useful
> information ever gets logged to the protected system logs. But at
> least no-one can modify the useless information.
Be smart, niall, syslog can only be compromised after the system
has been compromised.
> McKusick et al have this to say:
>
> Files marked immutable include those that are frequently the subject
> of attack by intruders (e.g., login and su). The append-only flag
> is typically used for critical system logs. If an intruder breaks
> in, he will be unable to cover his tracks. Although simple in
> concept, these two features improve the security of a system
> dramatically.
Since the intruder cannot reverse time, he cannot cover his tracks
in the system log. Just as McKusick said! (wow, he must have known
about the time thing too!)
> Why do they advocate protecting login and su if such protection can
> be trivially defeated using the same techniques we demonstrated in
> the attack on inetd? And why do they claim these features improve the
> security of a system "dramatically" if they can be bypassed so easily?
> Either they didn't read the chflags man page (hmm, I think they wrote it),
> they advocate partial security (hmm, don't think so), or there is a bug.
> I believe the latter is the case.
Because protecting login and su will protect the persistant system.
Yes, the running system may still be compromised. Securelevels does
not address that issue. (perhaps your stance could be summed up
as: "securelevels should protect the running system"?)
> Propogation of the immutable flag is the logical and correct thing to do.
> I agree that this behaviour is not explicitly documented, however it
> is a reasonable expectation that people hold. Secure levels become a
> farce without it.
I can see why one might think this is desirable, but it's hardly the only
obvious alternative. I wouldn't call securelevels minus this feature a
"farce" (that is, if securelevels plus this feature isn't considered
a farce as well :)
> Niall
Tim N.
------------------------------
Date: Sat, 27 Jun 1998 02:53:58 +0200
From: Duncan Simpson
Subject: check-ps 1.2 alpha 4 released
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I have just uploaded check-ps version 1.2 alpha 4 to the pub/word2x directory
on mars.astra.co.uk. I have also supplied a signature for pgp 2.x and pgp 5
users. You can obtain the keys from the file in the same directory or by
sending email to pgp@duncan.telstar.net (an automatic response robot, subject
and message contents junked). The licence is GPL.
The major features over 1.2alpha are
+ bug fixes (all known bugs are fairly minor)
+ configure fixes
+ kill scanning is now supported on linux.
For those who do not know about check-ps it is a security a;arm that pretends
to be httpd, possibly with a fake argument list (the name and argument list
are configurable by minor source changes). It can be configured to kill or
stop programs that are detected. If it understands the /proc format, which
currently means you have things not sent to me or are using linux, then it
will tell you all the information it can find. This understanding also enables
it to wipe out the attackers connection most of the time, assuming you tell it
to send signals.
The kill scanning can easily be "ported" to other platforms by supplying a
file called _killscan.h which #defines MAX_PROC to the largest
possible process id+1. Once this file is writen the configure script will
automatically sense its presence and turn on the kill scanning code. (If you
do write such a header please email it to me).
kill scanning tries all possible pids and uses the feature of most systems
that does error checks, and thus allow the chekcing of pids, without sending
any signal. This scanning is a lot will get people that hack the kernel code
that generates /proc entries to leave their evil processes out. Kudos for the
idea are due to Solar Designer.
Once enbaled you can select killing scanning by feeding check_ps -p or
- --killscan on the argument list. Please be aware that kill scanning, and
check-ps in general, is still experimental.
Assuming you want to receive reports via email when using the email option
please change cfg_email.h; at present the reports get sent to
dps@io.stargate.co.uk, which is probably not what you want. If anyone is
caught I would appreciate a quick note though.
Mirroring by others, including CERT, CIAC, etc is permitted.
- --
Duncan (-:
"software industry, the: unique industry where selling substandard goods is
legal and you can charge extra for fixing the problems."
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
Charset: noconv
iQA/AwUBNZRQq0ekq+3VXI08EQKZNgCg8KgIsEU9s4uL8W4xgOZn8FLol+oAoPLQ
WV1kuzUIy5Dy/xCw0xIDsgBx
=wWJA
-----END PGP SIGNATURE-----
------------------------------
Date: Fri, 26 Jun 1998 16:00:26 -0400
From: Scott Bartram
Subject: Re: {proc,kern}fs bug in FreeBSD (other systems?)
NetBSD is not vulnerable to this problem.
Brian Feldman wrote:
>
> In keeping compliant with the policies of BugTraq, I first gave the
> developers fair warning and a chance to fix the bugs. As per usual, the
> FreeBSD core team's response time was very quick, and the problem was
> fixed within the first day of reporting it to them. The purpose of this
> message is to alert anyone running FreeBSD (possibly NetBSD and OpenBSD,
> may want to check this out) that there are fixes out, and vulnerable
> systems should be fixed ASAP. The versions that are vulnerable are as
> follows (I am using procfs as the example), other systems should be
> checked out.
>
> FreeBSD 2.2.6-STABLE:
> * @(#)procfs_vnops.c 8.6 (Berkeley) 2/7/94
> *
> * $Id: procfs_vnops.c,v 1.24.2.1 1997/08/12 04:45:27 sef Exp $
>
> This seems to be using older code, and was never vulnerable.
>
> FreeBSD 3.0-CURRENT:
> * @(#)procfs_vnops.c 8.18 (Berkeley) 5/21/95
> *
> * $Id: procfs_vnops.c,v 1.60 1998/06/25 16:54:41 dt Exp $
>
> This is apparently a bug introduced in 4.4BSD-Lite2; this file's two id's
> reflect both that it is from 4.4BSD-Lite2, and that it was fixed in the
> FreeBSD-CURRENT source tree on 6/25/98, after I reported the bug, so
> anyone running 3.0-CURRENT should definitely update their {kern,proc}fs to
> prevent exploitation.
>
> Others:
> The best way to look for this is to try the following:
> grep hungry < `locate procfs_vnops.c`
> And see if there is any reference to the following panic (from a crash
> core bt)
> #1 0xf0119367 in panic (fmt=0xf5740bc8 "kernfs_readdir: not hungry")
> at ../../kern/kern_shutdown.c:423
>
> Any systems using 4.4BSD-Lite2 code should be interested in checking this
> out. Now of course, I can't leave off without revealing the actual
> exploit, now can I? The problem seems to be in the syscall usage of Linux
> programs in the 'emulation', and so far the only program I tested this
> with is RealPlayer 5.0 for Linux/i386. Attempting to browse /proc or /kern
> will cause a crash on a vulnerable system. i.e. "rvplayer /proc/curproc"
> or "rvplayer /kern/hostname".
>
> my->name = "Brian Feldman";
> my->email = "brianfeldman@hotmail.com";
> my->info = finger("green@feldman.dyn.ml.org");
------------------------------
Date: Sat, 27 Jun 1998 00:01:20 -0400
From: "Adam H. Pendleton"
Subject: Re: vulnerability in satan, cops & tiger
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
[**SNIP**]
> Satan is out of date anyway, a new version will hit us someday in
the future.
For those of you who like SATAN, it might be worth your while to check
out SAINT, which is an improved version of SATAN. We will be
releasing it July 1, for free of course. SAINT includes all of SATAN
original checks, updated to make them even more comprehensive, plus we
have added more. Some of the things we have added are:
-- Firewall support (scanning through a firewall, the original
SATAN could not do this)
-- Added checks for all relevant CERT advisories (and CIAC
bullitens)
-- Added more severity levels (red, yellow, brown, green)
-- Checks for more services (SMB, statd, DNS version, etc.)
-- Improved HTML interface
-- Updated documentation
-- Minor bug fixes (like the /tmp vulnerability mentioned)
Check out the SAINT page at http://www.wwdsi.com/saint
Oh, SAINT stands for Security Administrator's Integrated Network Tool.
Also, I want to say thanks to Dan and Wietse who have been pretty
supportive through this, and without who this product never would have
been made. SAINT version 1.2.1 will be available for download July 1.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Adam H. Pendleton
Corporate Security Officer
World Wide Digital Security, Inc.
Reston, Virginia
USA
[**SNIP**]
-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.5.5
iQA/AwUBNZRukGYLr94Yt2JdEQIz3ACghgu64cAtAHDlKv9OmuwinYZmqZAAn11Y
HFJgd5Erut9/m1QOtwjf4QXQ
=F0pi
-----END PGP SIGNATURE-----
------------------------------
Date: Sat, 27 Jun 1998 01:58:10 -0700
From: Tom Brown
Subject: Re: QPOPPER problem.... ONE crude patch...
On Sat, 27 Jun 1998, Seth McGann wrote:
> Its come to my attention that systems around the internet are being
> exploited using a new remote overflow in Qualcomm's Popper server. Well,
> lets clear a few things up:
> 2. This vulnerability effects FreeBSD, OpenBSD, and Solaris x86 so far.
> Other systems are most certainly vulnerable. Linux does not appear
> vulnerable. To test, simply send the sever several thousand characters and
> see if it crashed. Check the return address to see if it matches.
QPopper 2.4 (which is the current stable package, I just checked
qpopper2.41beta1 from ftp.qualcomm.com and it has the same problem... :-[)
on Linux ** IS ** vulnerable... and I see no reason why we shouldn't
expect it to be ...
pop_msg.c does a
vsprintf(mp,format,ap);
at line 66 as Seth pointed out... into a fixed length buffer (on the
stack) pointed to by mp... the problem described is any command long
enough to overflow MAXLINELEN (1024) bytes when formatted as:
-ERR Unknown command: "%"\r\n
changing this to something like:
vsnprintf(mp,sizeof(message)-(mp - message)-3,format,ap);
/* minor change -> vsnprintf, as per bugtraq Jun 27th posting...*/
/* -3 leaves room for null and \r\n appended below */
solves the immediate (or maybe I should say obvious), problem...
Wanna test your own box...?
perl -e 'print "e"x2000,"\r\nQUIT\r\n";' | nc -i 2 target 110
assuming you have netcat (nc) on your system... if not, just
telnet to your server and paste something like 20 lines of solid
characters into your telnet window... You'll get the -ERR
response back... at which point unpatched servers should core
dump... and you get "Connection closed by foreign host."
I haven't audited the code to see what other responses you can get out of
the pop server without having gone through the authentication stage (at
which point the POP server drops from root to the logged in user...) but a
cursory glance indicates that the user, apop, pass, quit, and "notvalid"
commands would be the most significant,
we also have a probably buffer overflow in pop_log.c (line 50), but it's
to a global variable, not a stack variable... same fix... simpler
actually...
change to something like:
/* vsprintf(msgbuf,format,ap); bugtraq fix #2 */
vsnprintf(msgbuf,sizeof(msgbuf)-1, format,ap);
... those are the only two occurences of vsprintf() in the code that I
see...
----------------------------------------------------------------------
tbrown@BareMetal.com | Courage is doing what you're afraid to do.
http://BareMetal.com/ | There can be no courage unless you're scared.
| - Eddie Rickenbacker
------------------------------
Date: Sat, 27 Jun 1998 03:24:04 -0400
From: Roy Hooper
Subject: patch for qpopper remote exploit bug
This is a simple case of the author(s) of qpopper not using vsnprintf where
they aught to have been. I have confirmed that qpopper-2.41beta1 is indeed
vulnerable to a remote exploit due to buffer overrun. I have not actually
tested the exploit, but have tested (and fixed) the buffer overrun in the
copy of qpopper running here.
The quick fix (for FreeBSD 2.2.2+, 3.0, and Solaris 2.6x86) is quite easy,
as both have the vsnprintf function. This patch is not guaranteed to solve
the problem, but appears to do so.
*** qpopper2.41beta1/pop_log.c Sat Jun 27 03:19:05 1998
--- qpopper2.41beta1-broken/pop_log.c Sat Jun 27 03:18:37 1998
***************
*** 47,53 ****
#endif
#ifdef HAVE_VPRINTF
! vsnprintf(msgbuf,sizeof(msgbuf),format,ap);
#else
# ifdef PYRAMID
(void)sprintf(msgbuf,format, arg1, arg2, arg3, arg4, arg5, arg6);
--- 47,53 ----
#endif
#ifdef HAVE_VPRINTF
! vsprintf(msgbuf,format,ap);
#else
# ifdef PYRAMID
(void)sprintf(msgbuf,format, arg1, arg2, arg3, arg4, arg5, arg6);
*** qpopper2.41beta1/pop_msg.c Sat Jun 27 03:01:22 1998
--- qpopper2.41beta1-broken/pop_msg.c Sat Jun 27 02:59:05 1998
***************
*** 63,69 ****
/* Append the message (formatted, if necessary) */
if (format)
#ifdef HAVE_VPRINTF
! vsnprintf(mp,sizeof(message),format,ap);
#else
# ifdef PYRAMID
(void)sprintf(mp,format, arg1, arg2, arg3, arg4, arg5, arg6);
--- 63,69 ----
/* Append the message (formatted, if necessary) */
if (format)
#ifdef HAVE_VPRINTF
! vsprintf(mp,format,ap);
#else
# ifdef PYRAMID
(void)sprintf(mp,format, arg1, arg2, arg3, arg4, arg5, arg6);
--
Roy Hooper
Sr. Systems Administrator
Cyberus Online Inc.
-----Original Message-----
From: Seth McGann
To: BUGTRAQ@netspace.org
Date: Saturday, June 27, 1998 2:36 AM
Subject: !!! FLASH TRAFFIC !!! QPOPPER REMOTE ROOT EXPLOIT
>Its come to my attention that systems around the internet are being
>exploited using a new remote overflow in Qualcomm's Popper server. Well,
>lets clear a few things up:
>
>1. The working exploit was stolen from my development account,
>subsequently MANY sites were cracked in short order. Much of Efnet was
>compromised as power crazed script kiddies gained root access on IRCOP
>boxes, giving themselves O-lines.
>
>2. This vulnerability effects FreeBSD, OpenBSD, and Solaris x86 so far.
>Other systems are most certainly vulnerable. Linux does not appear
>vulnerable. To test, simply send the sever several thousand characters and
>see if it crashed. Check the return address to see if it matches.
>
>3. Due to massive exploitation the proper authorities have most likely
>been notified already. This is a bit of an emergency.
>
>4. You will NOT get the "exploit" from me, don't ask. If you think your
>"eleet" enough, do it yourself. I admit I had some help, but it took a
>while to figure out.
>
>5. The most obvious offender is the vsprintf() on line 66 of pop_msg.c.
>
>6. If you have a problem with my style, I'm sorry. I'm angry at both
>myself and the members of #conflict who I hold directly responsible for
>this breach. I will not name names, the offenders know who they are.
>
>7. When I have my head together I will post a patch tomorrow if one is not
>available by then.
>
>8. For now, disable qpopper or choose another solution till qpopper is
>secured.
>
>Thank you.
>
>
>
>Seth M. McGann / smm@wpi.edu "Security is making it
>http://www.wpi.edu/~smm to the bathroom in time."
>KeyID: 2048/1024/E2501C80
>Fingerprint 3344 DFA2 8E4A 977B 63A7 19E3 6AF7 4AE7 E250 1C80
>
------------------------------
Date: Sat, 27 Jun 1998 20:37:31 +1000
From: security-alert@NETBSD.ORG
Subject: NetBSD Security Advisory 1998-004: at(1) vulnerabilities.
-----BEGIN PGP SIGNED MESSAGE-----
NetBSD Security Advisory 1998-004
---------------------------------
Topic: Problem with at(1) allows any file to be read.
Version: NetBSD 1.3.2 and earlier. Fixed in NetBSD-current 19980626.
Severity: Local user may be able to read any file.
Abstract
- --------
Due to a bug in the at(1) program, any local user can queue any file on
the system for execution by /bin/sh, readable by root. As at(1) returns
errors to the submitter, it is possibly that they may obtain parts of
the file.
Technical Details
- -----------------
The at(1) sources use seteuid(2) to user ID swap between the user and
root. at(1) incorrectly was setting it's cached real and effective user
ID to 0 before opening a filename passed via the -f flag, allowing any
file readable by root to be read as commands to be executed. For
example, if at(1) was called like this:
% at -f /etc/master.passwd now + 1 minute
portions of /etc/master.passwd may be mailed back to the user. In this
example, the security of the passwords in /etc/master.passwd was
compromised.
Solutions and Workarounds
- -------------------------
The patch listed below changes at(1) to not change the cached real and
effective user ID values, but instead, switching to root as necessary.
By removing the `REDUCE_PRIV' call, and calling `PRIV_START' and
`PRIV_END' around the final fchmod(2), security is obtained.
If the patch can not be applied, the following command should be run as
root, to remove the set-user-ID flag from the at(1) binary:
# chmod u-s /usr/bin/at
Note that this will disable at(1) for normal users.
The patch has been made available for NetBSD 1.3, 1.3.1 and 1.3.2, and
can be found on the NetBSD FTP server:
ftp://ftp.NetBSD.ORG/pub/NetBSD/misc/security/patches/19980626-at
Thanks To
- ---------
The NetBSD Project would like to thank Wolfgang Rupprecht
for providing information about this problem,
and matthew green for providing a solution.
More Information
- ----------------
Information about NetBSD and NetBSD security can be found at
http://www.NetBSD.ORG/ and http://www.NetBSD.ORG/Security/.
Copyright 1998, The NetBSD Foundation, Inc. All Rights Reserved.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.1
iQCVAwUBNZTIYT5Ru2/4N2IFAQEJvAP7B+6NGxodePtt+/WrOzE/e4hu1PCLS1Le
DXvwLpvfwiaB3zOhIgGcVr1EzgX3O0mmQqy8eWaYjEP41+p1HfRZf7idTXmmqpQY
pkYAeWc5FwZ59mHy4/bYibPNUKTxBY/QMSmhtbI4hKg81Xm5sCQe800h58cDju0s
P3qy30MwaUw=
=B19v
-----END PGP SIGNATURE-----
------------------------------
Date: Sat, 27 Jun 1998 15:46:02 +0200
From: Miquel van Smoorenburg
Subject: Re: !!! FLASH TRAFFIC !!! QPOPPER REMOTE ROOT EXPLOIT
In article <19980627050419750.AAA323.373@dell166>,
Seth McGann wrote:
>Its come to my attention that systems around the internet are being
>exploited using a new remote overflow in Qualcomm's Popper server. Well,
Oops! Here's a fix, that also fixes another thing I noted: buffer overflow
in X-UIDL processing (compromise an account by sending mail to it ..)
You need to put "HAVE_VSNPRINTF" in popper.h yourself if your O/S is
not Linux and it supports vsnprintf()
Patch relative to qpopper-2.3, the latest free version:
diff -ruN qpopper-2.3.orig/pop_dropcopy.c qpopper-2.3/pop_dropcopy.c
--- qpopper-2.3.orig/pop_dropcopy.c Sat Mar 29 05:30:36 1997
+++ qpopper-2.3/pop_dropcopy.c Sat Jun 27 15:33:07 1998
@@ -462,6 +462,9 @@
} else
cp = "";
+ /* Make UIDL not longer then 128 chars, we use it
+ in sprintf() later on */
+ if (strlen(cp) >= 128) cp[127] = 0;
mp->uidl_str = (char *)strdup(cp);
mp->length += nchar + 1;
p->drop_size += nchar + 1;
diff -ruN qpopper-2.3.orig/pop_log.c qpopper-2.3/pop_log.c
--- qpopper-2.3.orig/pop_log.c Sat Mar 29 05:30:36 1997
+++ qpopper-2.3/pop_log.c Sat Jun 27 15:33:07 1998
@@ -18,7 +18,11 @@
* log: Make a log entry
*/
+#ifdef HAVE_VSNPRINTF
static char msgbuf[MAXLINELEN];
+#else
+static char msgbuf[MAXLINELEN*4];
+#endif
pop_log(va_alist)
va_dcl
@@ -46,6 +50,9 @@
arg6 = va_arg(ap, char *);
#endif
+#ifdef HAVE_VSNPRINTF
+ vsnprintf(msgbuf,sizeof(msgbuf),format,ap);
+#else
#ifdef HAVE_VSPRINTF
vsprintf(msgbuf,format,ap);
#else
@@ -57,6 +64,7 @@
# endif
va_end(ap);
#endif
+#endif
if (p->debug && p->trace) {
clock = time(0);
@@ -67,6 +75,8 @@
(void)fflush(p->trace);
}
else {
+ /* Protect syslog from too long messages */
+ if (strlen(msgbuf) >= 512) msgbuf[511] = 0;
syslog (stat,"%s",msgbuf);
}
diff -ruN qpopper-2.3.orig/pop_msg.c qpopper-2.3/pop_msg.c
--- qpopper-2.3.orig/pop_msg.c Sat Mar 29 05:30:36 1997
+++ qpopper-2.3/pop_msg.c Sat Jun 27 15:33:07 1998
@@ -34,7 +34,11 @@
#ifdef PYRAMID
char * arg1, *arg2, *arg3, *arg4, *arg5, *arg6;
#endif
+#ifdef HAVE_VSNPRINTF
char message[MAXLINELEN];
+#else
+ char message[MAXLINELEN * 4];
+#endif
va_start(ap);
p = va_arg(ap, POP *);
@@ -63,6 +67,9 @@
/* Append the message (formatted, if necessary) */
if (format)
+#ifdef HAVE_VSNPRINTF
+ vsnprintf(mp,sizeof(message) - strlen(mp) - 1, format,ap);
+#else
#ifdef HAVE_VSPRINTF
vsprintf(mp,format,ap);
#else
@@ -72,6 +79,7 @@
(void)sprintf(mp,format,((int *)ap)[0],((int *)ap)[1],((int *)ap)[2],
((int *)ap)[3],((int *)ap)[4]);
# endif
+#endif
#endif
va_end(ap);
diff -ruN qpopper-2.3.orig/popper.h qpopper-2.3/popper.h
--- qpopper-2.3.orig/popper.h Mon Mar 31 22:10:18 1997
+++ qpopper-2.3/popper.h Sat Jun 27 15:33:56 1998
@@ -128,6 +128,7 @@
#endif
#ifdef LINUX
+# define HAVE_VSNPRINTF
# define POP_MAILDIR "/var/spool/mail"
# define POP_DROP "/var/spool/mail/.%s.pop"
# define POP_TMPDROP "/var/spool/mail/tmpXXXXXX"
--
Miquel van Smoorenburg | Our vision is to speed up time,
miquels@cistron.nl | eventually eliminating it.
------------------------------
Date: Sat, 27 Jun 1998 10:16:22 -0500
From: Aleph One
Subject: Re: (FWD) QPOPPER REMOTE ROOT EXPLOIT
---------- Forwarded message ----------
Date: Sat, 27 Jun 1998 03:26:51 -0700
From: "Jordan K. Hubbard"
To: bow
Cc: Igor Roshchin , freebsd-security@FreeBSD.ORG
Subject: Re: (FWD) QPOPPER REMOTE ROOT EXPLOIT
> This is a realllly quick fix.
> There is probably 100 ways to do it better, but this is better then turning
> qpopper off.
I've already committed a slightly more intelligent fix to this
problem. Thanks!
- Jordan
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe security" in the body of the message
------------------------------
Date: Sat, 27 Jun 1998 01:11:15 -0600
From: Theo de Raadt
Subject: Re: !!! FLASH TRAFFIC !!! QPOPPER REMOTE ROOT EXPLOIT
> 2. This vulnerability effects FreeBSD, OpenBSD, and Solaris x86 so far.
Nonsense. OpenBSD does not ship with a popper.
------------------------------
Date: Sat, 27 Jun 1998 09:35:54 -0700
From: Jason Ackley
Subject: Re: QPOPPER problem....
On Sat, 27 Jun 1998, Tom Brown wrote:
> perl -e 'print "e"x2000,"\r\nQUIT\r\n";' | nc -i 2 target 110
>
> assuming you have netcat (nc) on your system... if not, just
> telnet to your server and paste something like 20 lines of solid
> characters into your telnet window... You'll get the -ERR
> response back... at which point unpatched servers should core
> dump... and you get "Connection closed by foreign host."
Stock BSDi 3.0(3.1) all the latest patches(M310-034) DOES core dump , but
does not print out the 'ERR', so BSDi people may want to keep that in
mind..
Example:
$ perl -e 'print "e"x2000,"\r\nQUIT\r\n";' | nc -i 2 localhost 110
+OK QPOP (version 2.2-krb-IV) at llama.ackley.net starting. <
$ ls -l /pop* ; date
-rw------- 1 root wheel 155648 Jun 27 09:32 /popper.core
Sat Jun 27 09:32:11 PDT 1998
$
I also tested with 2.4, and 2.41beta1, applying patches now and will see
what it does..
Cheers,
-----
Jason Ackley
------------------------------
Date: Sat, 27 Jun 1998 18:31:05 +0200
From: Daniel Ryde
Subject: Re: QPOPPER problem.... ONE crude patch...
On Sat, 27 Jun 1998, Tom Brown wrote:
> vsnprintf(mp,sizeof(message)-(mp - message)-3,format,ap);
Dangerous, if the string is truncated it will skip the null termination,
then later the strcat might fail miserably (unless all arcitectures makes
for sure that, when allocated, the string is filled with null, which I
really doubt). Another note is the next lines of sprintf (architectures
that dont have vsprintf) that will have the same problem as vsprintf.
Change these to snprintf in a similar way, and add a null to the end.
Best Regards
Daniel Ryde, System Administrator
__________________________________________________________________________
Tripnet AB Visit Address: Telephone: +46 31 7252500
Box 5071 Avagen 42 Facsimile: +46 31 7252501
S-402 22 GOTEBORG GOTEBORG Email: ryde@tripnet.se
Sweden Sweden
------------------------------
Date: Sat, 27 Jun 1998 21:32:41 +0300
From: Yiorgos Adamopoulos
Subject: Re: QPOPPER problem.... ONE crude patch...
On Sat, Jun 27, 1998 at 01:58:10AM -0700, Tom Brown wrote:
> perl -e 'print "e"x2000,"\r\nQUIT\r\n";' | nc -i 2 target 110
can someone try this on a Solaris2.6 (sparc) ? I just did and it did not
core dump ...
------------------------------
Date: Sat, 27 Jun 1998 15:47:39 -0300
From: "Bruno Lopes F. Cabral"
Subject: Re: QPOPPER problem....
Hi there
Here is the proper join of Miquel van Smoorenburg and Roy Hooper
security patches applied to qpopper 2.4.
as I mantain the rpm version of pammified qpopper, you could grab everything
from ftp://ftp.openline.com.br/mirror/contrib/qpopper-2.4-2.src.rpm
!3runo
diff -uNr qpopper2.4-orig/pop_dropcopy.c qpopper2.4/pop_dropcopy.c
--- qpopper2.4-orig/pop_dropcopy.c Fri Sep 12 17:23:02 1997
+++ qpopper2.4/pop_dropcopy.c Sat Jun 27 14:41:01 1998
@@ -457,6 +457,9 @@
} else
cp = "";
+ /* Make UIDL not longer then 128 chars, we use it
+ in sprintf() later on */
+ if (strlen(cp) >= 128) cp[127] = 0;
mp->uidl_str = (char *)strdup(cp);
mp->length += nchar + 1;
p->drop_size += nchar + 1;
diff -uNr qpopper2.4-orig/pop_log.c qpopper2.4/pop_log.c
--- qpopper2.4-orig/pop_log.c Thu Sep 11 21:21:21 1997
+++ qpopper2.4/pop_log.c Sat Jun 27 14:41:57 1998
@@ -47,7 +47,7 @@
#endif
#ifdef HAVE_VPRINTF
- vsprintf(msgbuf,format,ap);
+ vsnprintf(msgbuf,sizeof(msgbuf),format,ap);
#else
# ifdef PYRAMID
(void)sprintf(msgbuf,format, arg1, arg2, arg3, arg4, arg5, arg6);
@@ -67,6 +67,8 @@
(void)fflush(p->trace);
}
else {
+ /* Protect syslog from too long messages */
+ if (strlen(msgbuf) >= 512) msgbuf[511] = 0;
syslog (stat,"%s",msgbuf);
}
diff -uNr qpopper2.4-orig/pop_msg.c qpopper2.4/pop_msg.c
--- qpopper2.4-orig/pop_msg.c Thu Sep 11 21:21:41 1997
+++ qpopper2.4/pop_msg.c Sat Jun 27 14:42:42 1998
@@ -63,7 +63,7 @@
/* Append the message (formatted, if necessary) */
if (format)
#ifdef HAVE_VPRINTF
- vsprintf(mp,format,ap);
+ vsnprintf(mp,sizeof(message) - strlen(mp) -1,format,ap);
#else
# ifdef PYRAMID
(void)sprintf(mp,format, arg1, arg2, arg3, arg4, arg5, arg6);
------------------------------
Date: Sat, 27 Jun 1998 16:16:05 -0400
From: Jeff Haas
Subject: Re: QPOPPER problem....
On Sat, Jun 27, 1998 at 09:35:54AM -0700, Jason Ackley wrote:
> Stock BSDi 3.0(3.1) all the latest patches(M310-034) DOES core dump , but
> does not print out the 'ERR', so BSDi people may want to keep that in
> mind..
> I also tested with 2.4, and 2.41beta1, applying patches now and will see
> what it does..
2.41beta works perfectly fine for 2.1 and 3.1 of BSD/OS after patching.
However, one of the patches mentioned here on the list was not correct.
Additionally, we incorporated the change to drop_copy.
If anyone wants a pre-compiled binary for 2.1 and 3.1, feel free
to drop me a line.
We have applied the following:
*** qpopper2.41beta1/pop_msg.c Wed Nov 19 16:20:38 1997
--- qpopper2.41beta1.new/pop_msg.c Sat Jun 27 15:27:50 1998
***************
*** 63,69 ****
/* Append the message (formatted, if necessary) */
if (format)
#ifdef HAVE_VPRINTF
! vsprintf(mp,format,ap);
#else
# ifdef PYRAMID
(void)sprintf(mp,format, arg1, arg2, arg3, arg4, arg5, arg6);
--- 63,69 ----
/* Append the message (formatted, if necessary) */
if (format)
#ifdef HAVE_VPRINTF
! vsnprintf(mp,sizeof(message) - (mp-message)- 3, format,ap);
#else
# ifdef PYRAMID
(void)sprintf(mp,format, arg1, arg2, arg3, arg4, arg5, arg6);
*** qpopper2.41beta1/pop_log.c Wed Nov 19 16:20:38 1997
--- qpopper2.41beta1.new/pop_log.c Sat Jun 27 14:07:19 1998
***************
*** 47,53 ****
#endif
#ifdef HAVE_VPRINTF
! vsprintf(msgbuf,format,ap);
#else
# ifdef PYRAMID
(void)sprintf(msgbuf,format, arg1, arg2, arg3, arg4, arg5, arg6);
--- 47,53 ----
#endif
#ifdef HAVE_VPRINTF
! vsnprintf(msgbuf,sizeof(msgbuf),format,ap);
#else
# ifdef PYRAMID
(void)sprintf(msgbuf,format, arg1, arg2, arg3, arg4, arg5, arg6);
*** qpopper2.41beta1/pop_dropcopy.c Wed Nov 19 16:20:38 1997
--- qpopper2.41beta1.new/pop_dropcopy.c Sat Jun 27 14:11:47 1998
***************
*** 456,461 ****
--- 456,462 ----
uidl_found--; /*roll over as though it hasn't seen anything*/
continue;
}
+ if (strlen(cp) >= 128) cp[127] = 0;
mp->uidl_str = (char *)strdup(cp);
mp->length += nchar + 1;
p->drop_size += nchar + 1;
> Jason Ackley
P.S.
Does anyone have any tricks for debugging this type of code when launched
in a daemon situation? The core dumps are not useful since the stack is
smashed and I don't know how to recover any valid stack frames.
--
Jeffrey Haas -+- jmh@msen.com -+- http://www.msen.com/~jmh
/\/\sen, Inc. "Michigan's Best Run Internet Service Provider."
------------------------------
Date: Sat, 27 Jun 1998 14:15:26 -0600
From: "Aaron D. Gifford"
Subject: More patch ideas for qpopper
I noticed that popper.h had a #define for MAXPARMLEN but never used it. I
decided it's a good idea and added it to my popper on top of some of the other
patches I've seen here. I bumped up the MAXPARMLEN size to 16. So far on my
FreeBDS-based system with only 5,000 users, I haven't noticed any problems
yet.
Is there a reason the qpopper folks didn't do this in the first place? The
defined it, but never used it.
Puzzled,
Aaron out.
diff -p qpopper2.41beta1/pop_parse.c qpopper2.41beta1+infowest/pop_parse.c
*** qpopper2.41beta1/pop_parse.c Wed Nov 19 14:20:38 1997
--- qpopper2.41beta1+infowest/pop_parse.c Sat Jun 27 13:48:30 1998
*************** char * buf; /* Pointer
*** 26,31 ****
--- 26,32 ----
{
char * mp;
register int i;
+ register int parmlen;
/* Loop through the POP command array */
for (mp = buf, i = 0; ; i++) {
*************** char * buf; /* Pointer
*** 45,52 ****
/* Point to the start of the token */
p->pop_parm[i] = mp;
/* Search for the first space character (end of the token) */
! while (!isspace(*mp) && *mp) mp++;
/* Delimit the token with a null */
if (*mp) *mp++ = 0;
--- 46,68 ----
/* Point to the start of the token */
p->pop_parm[i] = mp;
+ /* Start counting the length of this token */
+ parmlen = 0;
+
/* Search for the first space character (end of the token) */
! while (!isspace(*mp) && *mp) {
! mp++;
! if (++parmlen > MAXPARMLEN) {
! /* Truncate parameter to the max. allowable size */
! *mp = '\0';
! if (i == 0) {
! pop_msg(p,POP_FAILURE,"Command \"%s\"
(truncated) exceedes maximum permitted size.",
! p->pop_command);
! } else {
! pop_msg(p,POP_FAILURE,"Argument %d \"%s\"
(truncated) exceeds maximum permitted size.",
! i, p->pop_parm[i]);
! }
! return(-1);
! }
! }
/* Delimit the token with a null */
if (*mp) *mp++ = 0;
diff -p qpopper2.41beta1/popper.h qpopper2.41beta1+infowest/popper.h
*** qpopper2.41beta1/popper.h Wed Nov 19 14:20:39 1997
--- qpopper2.41beta1+infowest/popper.h Sat Jun 27 13:59:57 1998
***************
*** 64,70 ****
#define MAXMSGLINELEN MAXLINELEN
#define MAXCMDLEN 4
#define MAXPARMCOUNT 5
! #define MAXPARMLEN 10
#define ALLOC_MSGS 20
#ifndef OSF1
--- 69,75 ----
#define MAXMSGLINELEN MAXLINELEN
#define MAXCMDLEN 4
#define MAXPARMCOUNT 5
! #define MAXPARMLEN 16
#define ALLOC_MSGS 20
#ifndef OSF1
------------------------------
Date: Sat, 27 Jun 1998 21:21:13 +0300
From: Andres Kroonmaa
Subject: Re: patch for qpopper remote exploit bug
On 27 Jun 98, at 3:24, Roy Hooper wrote:
> This is a simple case of the author(s) of qpopper not using vsnprintf where
> they aught to have been. I have confirmed that qpopper-2.41beta1 is indeed
> vulnerable to a remote exploit due to buffer overrun. I have not actually
> tested the exploit, but have tested (and fixed) the buffer overrun in the
> copy of qpopper running here.
>
> The quick fix (for FreeBSD 2.2.2+, 3.0, and Solaris 2.6x86) is quite easy,
> as both have the vsnprintf function. This patch is not guaranteed to solve
> the problem, but appears to do so.
>
> *** qpopper2.41beta1/pop_log.c Sat Jun 27 03:19:05 1998
> --- qpopper2.41beta1-broken/pop_log.c Sat Jun 27 03:18:37 1998
> ***************
> *** 47,53 ****
> #endif
>
> #ifdef HAVE_VPRINTF
> ! vsnprintf(msgbuf,sizeof(msgbuf),format,ap);
> #else
Yeah, but what about systems that do _not_ have vsnprintf()?
Using calls without bounds checks can be justified as long
as it is made dead sure that no bounds would be ever exceeded.
In current case, buffers overflow because qpopper accepts
way too long commands. Easiest fix is to limit max command
length at safer lower length during call to tgets()
----------------------------------------------------------------------
Andres Kroonmaa mail: andre@online.ee
Network Manager
Organization: MicroLink Online Tel: 6308 909
Tallinn, Sakala 19 Pho: +372 6308 909
Estonia, EE0001 http://www.online.ee Fax: +372 6308 901
----------------------------------------------------------------------
------------------------------
End of BUGTRAQ Digest - 26 Jun 1998 to 27 Jun 1998
**************************************************