Date: Sat, 27 Jun 1998 00:02:40 -0400
Reply-To: Bugtraq List
Sender: Bugtraq List
From: Automatic digest processor
Subject: BUGTRAQ Digest - 25 Jun 1998 to 26 Jun 1998
To: Recipients of BUGTRAQ digests
Message-Id: <19980627040501Z97138-23463+8@brimstone.netspace.org>
There are 15 messages totalling 1317 lines in this issue.
Topics of the day:
1. security hole in mailx (3)
2. Vulnerability in Some Usages of PKCS#1
3. SSL Vulnerability
4. {proc,kern}fs bug in FreeBSD (other systems?)
5. vulnerability in satan, cops & tiger (3)
6. Bug is sudo?
7. guestbook script is still vulnerable under apache (2)
8. dip-3.3.7p exploit (stackpatch_
9. textcounter.pl (alternate fix)
10. IRIX mailx(1) Buffer Overrun Vulnerability
----------------------------------------------------------------------
Date: Thu, 25 Jun 1998 23:53:56 -0500
From: "Patrick J. Volkerding"
Subject: Re: security hole in mailx
On Fri, 26 Jun 1998, Alvaro Martinez Echevarria wrote:
> On Thu, 25 Jun 1998, gold wrote:
>
> > sh-2.02$ id
> > uid=1001(gold) gid=8(mem) groups=100(users)
> > this is on slackware 3.5
> > slack 3.3 was complete euid root
> > thank-you for notice alvaro
>
> Ooops. I forgot about slackware, I didn't report this to them. So
> it seems that under both Slackware 3.3 and 3.5 this bug is a
> direct root compromise:
>
> -under 3.3 you get a direct euid=0; and
> -under 3.5 you are group 8(mem), something that leads me to think
> that the overflow code was executed as root. Because I don't think
> mailx is setgid "mem" in slackware 3.5.
Actually, the mailx binary in Slackware 3.3/3.4 is not setuid or setgid:
-rwxr-xr-x 1 root bin 59420 Aug 16 1996 Mail
I doubt this could be exploited.
The mailx in Slackware 3.5 (mailx-8.1.1-9) is supplied setgid mail, and
before applying the patch you could probably exploit the overflow to get
group mail (12).
> I'm sending this (and the original report) to Patrick Volkerding.
It would have been nice to get some advance notice, but I caught the post
on BugTraq (after all, BugTraq *is* the breakfast of champions :) and have
a fixed mailx.tgz binary package up for FTP:
ftp://ftp.cdrom.com/pub/linux/slackware/slakware/n3/mailx.tgz
MD5 sum for the package:
6f7047cf74513b34e35610bebf25c82e mailx.tgz
The patch is also on the same site:
ftp://ftp.cdrom.com/pub/linux/slackware/source/n/mailx/mailx-overflow.diff.gz
And, the MD5 sum on this one is:
c2d69e4823c6c5228a3cb183aeb21720 mailx-overflow.diff.gz
Take care,
Patrick J. Volkerding
Slackware Linux maintainer
------------------------------
Date: Fri, 26 Jun 1998 09:54:57 -0500
From: Aleph One
Subject: Vulnerability in Some Usages of PKCS#1
=============================================================================
CERT* Advisory CA-98.07
Original issue date: June 26, 1998
Topic: Vulnerability in Some Usages of PKCS#1
-----------------------------------------------------------------------------
The CERT Coordination Center has received a report regarding a vulnerability
in some implementations of products utilizing RSA Laboratories' Public-Key
Cryptography Standard #1 (PKCS#1). Under some situations, a sophisticated
intruder may be able to use the vulnerability in PKCS#1 to recover
information from SSL-encrypted sessions.
The CERT/CC team recommends that sites install patches immediately as
described in Appendix A. Appendix A also contains pointers to web pages
containing additional information maintained by some vendors.
We will update this advisory as we receive additional information. Please
check our advisory files regularly for updates that relate to your site.
-----------------------------------------------------------------------------
I. Description
PKCS#1 is a standard for encrypting data using the RSA public-key
cryptosystem. Its intended use is in the construction of digital
signatures and digital envelopes.
One use for the digital envelopes constructed using PKCS#1 is to provide
confidentiality during the session key negotiation of an SSL-encrypted
session. The SSL protocol is widely used to encrypt traffic to and from
web servers to protect the privacy of information such as personal data
or a credit card number, as it traverses the internet. A sophisticated
intruder may be able to use the vulnerability in PKCS#1 to recover
information from an SSL-encrypted session.
Web pages employing SSL are accessed using the HTTPS protocol, rather
than the HTTP protocol.
More information about PKCS#1 can be found at
http://www.rsa.com/rsalabs/pubs/PKCS/
Additional information regarding this vulnerability will be
available at
http://www.bell-labs.com
This vulnerability does not affect all PKCS#1-enabled products. The
attack is not effective against protocols in which there is not an
interactive session setup, or where the error messages returned by the
server do not distinguish among the types of failures. In particular,
this vulnerability does not affect S/MIME or SET.
II. Impact
Under some circumstances, an intruder who is able to observe an
SSL-encrypted session, and subsequently interrogate the server involved
in the session, may be able to recover the session key used in that
session, and then recover the encrypted data from that session.
The vulnerability can only be exploited if the intruder is able to make
repeated session-establishment attempts to the same vulnerable web server
which was involved in the original session. In addition, the server must
return error messages that distinguish between several modes of
failure. Although the number of session-establishment requests is large,
it is significantly more efficient than a brute-force attack against the
session key. Note that, although web servers comprise the majority of
vulnerable servers, other PKCS#1-enabled servers may be vulnerable.
Note that the server's public and private key are not at risk from this
vulnerability, and that an intruder is only able to recover data from a
single session per attack. Compromising a single session does not give an
intruder any additional ability to compromise subsequent sessions.
Further, as mentioned above, this vulnerability does not affect all
PKCS#1-enabled products.
III. Solution
A. Obtain and install a patch for this problem.
Appendix A contains input from vendors who have provided information
for this advisory. We will update the appendix as we receive more
information. If you do not see your vendor's name, the CERT/CC did
not hear from that vendor. Please contact your vendor directly.
B. Although applying vendor patches is the recommended course of action,
you may wish to consider some of the following steps to reduce your
exposure to this vulnerability:
-- Examine your log files for repeated error messages indicating
failed requests for session-establishment. For example, sites using
C2Net's Stronghold server would see error messages of the form
[Tue Jun 23 22:08:17 1998] SSL accept error
1575:error:0407006B:rsa routines:RSA_padding_check_PKCS1_type_2:block type
is not 02:rsa_pk1.c:207
1575:error:04064072:rsa routines:RSA_EAY_PRIVATE_DECRYPT:padding check
failed:rsa_eay.c:330
1575:error:1408B076:SSL routines:SSL3_GET_CLIENT_KEY_EXCHANGE:bad rsa
decrypt:s3_srvr.c:1259
-- If you are unable to upgrade for an extended period of time, you
may wish to consider obtaining a new public/private key pair for
servers. Changing the key pair only protects those sessions which may
have been previously recorded by an intruder. This does not prevent
an intruder from launching attacks against newly-recorded
sessions. This should only be considered in those cases where
upgrading is infeasible. Again, note that the public/private key pair
is not at risk from this vulnerability.
-- Avoid using the same public/private key pair across multiple
servers.
-- A large increase in CPU utilization or network traffic may
accompany an attack. If your web server does not provide sufficient
detail in its logs to detect failures, you may wish to look for
substantial deviation from established usage patterns, which may be
indicative of an attack.
Implementors and researchers should consult RSA Laboratories Bulletin
Number 7 for additional measures to reduce the effectiveness of this
attack. This document will be available at
http://www.rsa.com/rsalabs/
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Appendix A - Vendor Information
Below is a list of the vendors who have provided information for this
advisory. We will update this appendix as we receive additional information.
If you do not see your vendor's name, the CERT/CC did not hear from that
vendor. Please contact the vendor directly.
C2Net Software, Inc.
-------------------
C2Net has developed a patch and is deploying new builds to combat this
problem. More information is available at
http://www.c2.net
Microsoft Corporation
---------------------
The Microsoft Product Security Response Team has produced an update
for the following affected Microsoft Internet server software:
- Microsoft Internet Information Server 3.0 and 4.0
- Microsoft Site Server 3.0, Commerce Edition
- Microsoft Site Server, Enterprise Edition
- Microsoft Exchange 5.0 and 5.5 (for SSL-enabled POP3 and SMTP)
Microsoft's Internet server software provides SSL 2.0, SSL 3.0, PCT
1.0, and TLS 1.0 for securing Internet-based communications. These
protocols are all implemented in a single file called SCHANNEL.DLL,
which is shared by the Microsoft Internet server software listed
above. Updating this single file will resolve this vulnerability for
these Microsoft server products.
No updates are required for Internet client software, such as Internet
Explorer.
This update is now available. Microsoft strongly recommends that
customers using secure SSL Internet services with any of the Microsoft
products listed above should update to the latest version of
SCHANNEL.DLL.
Please visit the Microsoft Security Advisor web site for more
information, or link directly to our Microsoft security
bulletin MS98-002 at
http://www.microsoft.com/security/bulletins/ms98-002.htm
Netscape Communications Corporation
-----------------------------------
Netscape recommends that all customers running Netscape Enterprise
Server software, Netscape Proxy Server, Netscape Messaging Server and
Netscape Collabra Server download and install a simple patch before an
attack ever happens.
Product updates and full information about the countermeasures are
available immediately from the Netscape Internet site at:
http://help.netscape.com/products/server/ssldiscovery/index.html
Open Market, Inc.
-----------------
Some of Open Market's products are affected by this
vulnerability. Patches are available. For more information, go to
http://www.openmarket.com/security
RSA Data Security, Inc.
-----------------------
Information from RSA regarding this vulnerability is available at
http://www.rsa.com/rsalabs/
SSLeay
------
Information and SSLeay source patches related to this vulnerability
are available at:
http://www.ssleay.org/announce/
-----------------------------------------------------------------------------
This vulnerability was originally discovered by Daniel Bleichenbacher of the
Secure Systems Research Department of Bell Labs, the research and development
arm of Lucent Technologies.
The CERT Coordination Center thanks Scott Schnell of RSA and Jason Garms of
Microsoft for reporting this problem to us and providing technical advice and
other valuable input into the construction of this advisory. In addition, our
thanks goes to Simona Nass, Douglas Barnes, and Tim Hudson of C2Net and David
Wagner of the University of California at Berkeley for the example log files
contained herein as well as additional technical advice and clarification
during the production of this advisory.
-----------------------------------------------------------------------------
If you believe that your system has been compromised, contact the CERT
Coordination Center or your representative in the Forum of Incident Response
and Security Teams (see http://www.first.org/team-info/).
CERT/CC Contact Information
----------------------------
Email cert@cert.org
Phone +1 412-268-7090 (24-hour hotline)
CERT personnel answer 8:30-5:00 p.m. EST(GMT-5) / EDT(GMT-4)
and are on call for emergencies during other hours.
Fax +1 412-268-6989
Postal address
CERT Coordination Center
Software Engineering Institute
Carnegie Mellon University
Pittsburgh PA 15213-3890
USA
Using encryption
We strongly urge you to encrypt sensitive information sent by email. We can
support a shared DES key or PGP. Contact the CERT/CC for more information.
Location of CERT PGP key
ftp://ftp.cert.org/pub/CERT_PGP.key
Getting security information
CERT publications and other security information are available from
http://www.cert.org/
ftp://ftp.cert.org/pub/
CERT advisories and bulletins are also posted on the USENET newsgroup
comp.security.announce
To be added to our mailing list for advisories and bulletins, send
email to
cert-advisory-request@cert.org
In the subject line, type
SUBSCRIBE your-email-address
---------------------------------------------------------------------------
Copyright 1998 Carnegie Mellon University. Conditions for use, disclaimers,
and sponsorship information can be found in
http://www.cert.org/legal_stuff/legal_stuff.html and
ftp://ftp.cert.org/pub/legal_stuff .
If you do not have FTP or web access, send mail to cert@cert.org with
"copyright" in the subject line.
*CERT is registered in the U.S. Patent and Trademark Office.
---------------------------------------------------------------------------
This file: ftp://ftp.cert.org/pub/cert_advisories/CA-98.07.PKCS
http://www.cert.org/nav/alerts.html
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Revision history
------------------------------
Date: Fri, 26 Jun 1998 09:48:19 -0500
From: Aleph One
Subject: SSL Vulnerability
http://www.c2.net/products/stronghold/support/PKCS1.php
Background
Last week, RSA Data Security notified C2Net Software of a potential
vulnerability that affects the SSL protocol. C2Net Software has
developed a pre-emptive patch which is implemented in the latest
version of Stronghold 2.3. This document is intended to address
questions C2Net customers may have about the implications of that
discovery to their own site.
Technical information
This vulnerability involves a chosen ciphertext attack discovered by
researcher Daniel Bleichenbacher at Bell Labs against
interactive key establishment protocols that use PKCS1, such as SSL.
This can result in the compromise of the session key used for a
particular session after repeatedly sending approximately one million
carefully constructed messages and observing the server's response.
Please see our press release and advisory for additional
details. RSA Labs brought this attack to our attention and their
site contains a more technical overview. CERT will also issue a
bulletin, as will a number of other web server vendors.
What does it mean?
There is potential for a sophisticated user to be able to decrypt a
recorded session's session key and use that to obtain the data
transmitted during that session if they have access to a server they
can use to send approximately one million carefully selected messages
to your server and see what errors it reports. Note that this attack
has to be repeated approximately a million times for each and every
session that an attacker wishes to compromise, because the server's
private key remains uncompromised as a result of this attack.
How can I tell if I'm being attacked?
For each of the approximately 1 million or so messages necessary to
attack a single session, the following 3 lines will be logged in your
ssl/error_log file:
1575:error:0407006B:rsa routines:RSA_padding_check_PKCS1_type_2:block
type is not 02:rsa_pk1.c:207
1575:error:04064072:rsa routines:RSA_EAY_PRIVATE_DECRYPT:padding check
failed:rsa_eay.c:330
1575:error:1408B076:SSL routines:SSL3_GET_CLIENT_KEY_EXCHANGE:bad rsa
decrypt:s3_srvr.c:1259
NOTE that this equates to about 300MB for an attack on a single
session. Although running out of space on the partition your log files
are written to could definitely be an indication, we suggest keeping
an eye out for any usual growth in the size of this file.
What can I do to protect myself?
This vulnerability has only been reported in a research environment
and there have not been reports of sites experiencing this attack
outside of that. However, the publication of this type of
vulnerability may enable sophisticated users to implement it.
Customers are urged to upgrade as a precaution to the latest
version of Stronghold 2.3, which supports this fix as of build
2010 for customers in the US/Canada, build 2051 for customers
elsewhere. You can determine which version you are running from the
output of httpsd -v.
What other vendors/products are affected?
All major vendors have announced that they are working on patched
versions of their web servers products to combat this potential
vulnerability. This vulnerability is not limited to web servers.
Products using SSL to do secure tunneling, for example, may also be
affected.
Sites with other information:
http://www.rsa.com/rsalabs/
http://www.ssleay.org/announce/pkcs1.html
http://www.microsoft.com/security/bulletins/ms98-002.htm
http://www.openmarket.com/security/
http://help.netscape.com/products/server/ssldiscovery/
http://www.consensus.com/ssl-rsa.html
ftp://ftp.psy.uq.oz.au/pub/Crypto/SSL/README.PKCS1
------------------------------
Date: Fri, 26 Jun 1998 13:53:41 -0400
From: Brian Feldman
Subject: {proc,kern}fs bug in FreeBSD (other systems?)
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: Fri, 26 Jun 1998 09:24:17 +0200
From: Marc Heuse
Subject: vulnerability in satan, cops & tiger
Hi ...
While doing a security audit on various tools I found /tmp race conditions
in the popular security programs cops 1.04, satan 1.1.1 and tiger 2.2.3 ...
All the following bugs can be used to create or overwrite any file on the
system, because these applications run usually under the root id.
Therefore a denial-of-service and depending on the system configuration
(and 'luck') a root compromise possible.
Satan v1.1.1
in the file bin/rex.satan:
tmp_file=/tmp/rex.$$
trap "$RM -f $tmp_file; exit" 0 1 2 3 15
[... several lines later ...]
$REX -a 1,1,1 $target date >$tmp_file 2>/dev/null
fix:
change the tmp_file= line to
tmp_file=./rex.$$
that's how it's done in the other scripts needing temporary files.
Note that the rex vulnerability check is not enabled in the standard
configuration. You have to change the satan.cf file for that, so we
can assume that 95% of the installations are not concerned. Satan
is out of date anyway, a new version will hit us someday in the future.
Well here's the quote of an email from wietse:
"A new SATAN version is in the works. However, all the software
still needs to be written, so don't expect to see it by this summer."
Cops v1.04 (see below for a patch)
in the file res_diff:
$AWK 'NR > 5' $old_file > /tmp/tmp.$$.foo
$AWK 'NR > 5' $2 > /tmp/tmp.$$.bar
in the file checkacct/ca.src:
(touch /tmp/makedots${THISSHELL};while [ -f /tmp/makedots${THISSHELL} ]; do
echownl(%.^); sleep 1; done)& 2>&1 >/dev/null;
touch follows this symlink -> any file can be created on the system
(what would be a nice attack for this? .nologin for dos?)
in the file extra_src/mail.chk:
PROG="/usr/tmp/mchk.p$$"
TEMP="/usr/tmp/mchk.t$$"
[...]
$RM -f $PROG
cat <<'EndOfProg' >$PROG
[...]
$RM -f $TEMP
$LS -lag | $AWK -f $PROG >$TEMP
Tiger v2.2.3
the $WORKDIR of tiger 2.2.3 is set to /tmp and many
temporary files are being written there (it would exeed
all limits to mention all the lines) ...
to prevent the raceconditions, $TIGER_HOME/tmp should be created by
default and $WORKDIR in the config file set to it.
See below for a patch.
closing remarks: I was shocked when I found these bugs. These security tools
have been around since years - and yet nobody had checked this ??
If this is a reflection of our security consciousness, well, we are in big
trouble since a long time and things are not getting better (especially with
M$ around)
Mit freundlichen Gruessen,
Marc Heuse
This message and any statements expressed therein are those of myself
and not of the Deutsche Bank AG or its subsidiary companies.
Type Bits/KeyID Date User ID
pub 2048/DB5C03C5 1997/09/23 Marc Heuse
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.3i
mQENAzQnbFEAAAEIAL/tj4hn/DVjEWAZhuqRdxZQDy5B+gZbE0CD/mUnZqpem+9L
KY+I8te7jMfTQExzqn5jYb5BaibT0SbEBWSx9Gha8EiBLAVcAjvrXpV+HJLcnPRG
YDk5a3s7GrA+QVHbbd9DWgqjMfUMw9oUDAhhjgK20SeOtFGBD2U17GkQF6TK7EjC
CTOuz2Hx/tisDuroJJnxZdbLNvCceOf/D/bbFcR7DfnEJWJ3f9JC4fibZMlX5rXL
Ct/TKhZMd4d42uL7L4KvkT5JCnFuEw1jRDPpBjZ030cK2uWCM//iEVLGmGKOs6Pg
o3Lfnnd6I6bTPHgrNsapNWmocbIGDC/4w9tcA8UABRG0Jk1hcmMgSGV1c2UgPG1h
cmMuaGV1c2VAbWFpbC5kZXViYS5jb20+iQEVAwUQNCdsUQwv+MPbXAPFAQFWEwf5
AWt6PbKLLCCBPnzBMdXatKEJvNzrZRXNSpbgKQUDAKApRUnOkDJ9yp3tfJG0/BsL
XBf+ldmjjoo/OZeWhIhNb71bbCs8BK7/YK5LKef2eq4pzSiWYosrOfjlfyOVhAiP
AiWYtK/HBELy6Zs8QwoPX0QX0+R2+ocMS0TDz7nwBgO5wcj3yMU0geTrnlDpJdj1
RgFQLE6T9qO5coRjj1EAoT5gQMxP9L4TQuifYiQ6S2vh6blr3amjPohKSDzZ62/x
rQ1KMXJd7MlMQndn8UwKt4XgoFIsZOFRrkDiXfm6zFnH40UcotoA+Ygojp52+Y6A
MuixTDbuf3Jph2jEG6r4Dw==
=/n63
-----END PGP PUBLIC KEY BLOCK-----
COPS PATCH
--- res_diff.orig Thu Jun 18 09:54:39 1998
+++ res_diff Thu Jun 18 10:02:06 1998
@@ -38,16 +38,24 @@
fi
# has anything changed?
-$AWK 'NR > 5' $old_file > /tmp/tmp.$$.foo
-$AWK 'NR > 5' $2 > /tmp/tmp.$$.bar
+umask 077
+mkdir /tmp/cops-res_diff.$$ || {
+ echo "can't create /tmp/cops-res_diff.$$ - possible attack, aborting."
+ exit 1
+}
+TMP_FOO="/tmp/cops-res_diff.$$/tmp.$$.foo"
+TMP_BAR="/tmp/cops-res_diff.$$/tmp.$$.bar"
-if $TEST -n "$DIFF /tmp/tmp.$$.foo /tmp/tmp.$$.bar" ; then
- $RM -f /tmp/tmp.$$.foo /tmp/tmp.$$.bar
+$AWK 'NR > 5' $old_file > $TMP_FOO
+$AWK 'NR > 5' $2 > $TMP_BAR
+
+if $TEST -n "$DIFF $TMP_FOO $TMP_BAR" ; then
+ $RM -f $TMP_FOO $TMP_BAR
$ECHO There is a difference....
exit 1
fi
-$RM -f /tmp/tmp.$$.foo /tmp/tmp.$$.bar
+$RM -rf /tmp/cops-res_diff.$$
# echo There is no difference....
exit 0
# end
--- extra_src/mail.chk.orig Thu Jun 18 09:55:02 1998
+++ extra_src/mail.chk Thu Jun 18 10:01:52 1998
@@ -19,10 +19,14 @@
RM=/bin/rm
MAILDIR=/var/spool/mail
#
-PROG="/usr/tmp/mchk.p$$"
-TEMP="/usr/tmp/mchk.t$$"
-#
umask 077
+mkdir /usr/tmp/cops-mail.chk.$$ || {
+ echo "can't create /usr/tmp/cops-mail.chk.$$ - possible attack, aborting"
+ exit 1
+}
+PROG="/usr/tmp/cops-mail.chk.$$/mchk.p$$"
+TEMP="/usr/tmp/cops-mail.chk.$$/mchk.t$$"
+#
#
# Unpack the awk script from a "hereis".
# The script reports files with bad permissions or where filename !=
@@ -45,5 +49,5 @@
fi
#
# Clean up.
-$RM -f $TEMP $PROG
+$RM -rf /usr/tmp/cops-mail.chk.$$
exit 0
--- checkacct/ca.src.orig Thu Jun 18 09:54:51 1998
+++ checkacct/ca.src Thu Jun 18 10:08:20 1998
@@ -351,12 +351,19 @@
#
# define the waiting routine that prints those neat dots
#
+umask 077
+mkdir /tmp/cops-ca.src.$$ || {
+ echo "can't create /tmp/cops-ca.src.$$ - aborting"
+ exit 1
+}
+
make_dots='
if [ ${VERBOSE} -eq 1 ]; then
- (touch /tmp/makedots${THISSHELL};while [ -f
/tmp/makedots${THISSHELL} ]; do echownl(%.^); sleep 1; done)& 2>&1
+ touch /tmp/cops-ca.src.$$/makedots${THISSHELL};while [ -f
/tmp/cops-ca.src.$$/makedots${THISSHELL} ];
+ do echownl(%.^); sleep 1; done)& 2>&1 >/dev/null;
fi;'
-stop_dots='sleep 1; /bin/rm -rf /tmp/makedots${THISSHELL};'
+stop_dots='sleep 1; /bin/rm -f /tmp/cops-ca.src.$$/makedots${THISSHELL};'
if [ 1 -eq $VERBOSE ]; then
@@ -542,6 +549,7 @@
fi;
%eval^ $stop_dots
+rm -rf /tmp/cops-ca.src.$$
if [ ${VERBOSE} -eq 1 ]; then
echo "Step 3 complete."
TIGER PATCH
--- config.orig Thu Jun 18 09:43:22 1998
+++ config Thu Jun 18 09:50:59 1998
@@ -12,9 +12,6 @@
#-----------------------------------------------------------------------------
#
# space, tab, newline
-TigerLogDir='.'
-TigerWorkDir='/tmp'
-TigerBinDir='$BASEDIR/bin'
checkfile()
{
@@ -53,8 +50,17 @@
BASEDIR='.'
fi
+TigerLogDir='.'
+TigerWorkDir="$BASEDIR/tmp"
+TigerBinDir='$BASEDIR/bin'
+
+[ -d $TigerWorkDir ] || mkdir $TigerWorkDir || {
+ echo "can't create TigerWorkDir!"
+ exit 1
+}
+
LOGDIR=${TigerLogDir:=.}
- WORKDIR=${TigerWorkDir:=${TMPDIR:=/tmp}}
+ WORKDIR=${TigerWorkDir:=${TMPDIR:=$BASEDIR/tmp}}
EXPLAINREPORT=N
SERVERCHECK=N
Tiger_TESTMODE=N
------------------------------
Date: Fri, 26 Jun 1998 06:12:11 +0200
From: Alvaro Martinez Echevarria
Subject: Re: security hole in mailx
On Thu, 25 Jun 1998, Casper Dik wrote:
> It should be noted that homedir itself, at least on Solaris,,
> is a char homedir[PATHSIZE] which is copied from the environment.
> (This never stops to amaze me; why *copy* the result from getenv()?)
> You'd want to fix the overflow of homedir too; looks like there
> are a few other overflows as well.
Under the Linux sources, homedir is a char *, that is malloc'ed
and filled from the environment variable value. A nice way to
waste some CPU, yeah.
By the way, assuming that homedir is a global variable in
Solaris, that could be the reason why the overflow doesn't seem
to reach the stack (such has been reported to me in several
messages). But that may have changed in the last version: a 5.6
mailx with the latest patches applied dies by "Bus Error" (as
reported by Jared Buntain) instead of "Segmentation Fault". I
haven't checked it, but sounds to me like a stack overflow.
> I don't particularly care for arguments as "seem exploitable".
> The homedir data segment buffer overflow may well be exploitable;
> in the Solaris sources, there is at least one other buffer overflow
> on the stack.
Of course, the patch I sent addresses all the buffer overflows I
detected after a quick inspection. Not only the "seems
exploitable" one.
Regards.
.------------------------------------------------------------------.
| Alvaro Martínez Echevarría | LANDER SISTEMAS |
| alvaro@lander.es | Pº Castellana, 121 |
`--------------------------------| 28046 Madrid, SPAIN |
| Tel: +34-91-5562883 |
| Fax: +34-91-5563001 |
`---------------------------------'
------------------------------
Date: Fri, 26 Jun 1998 03:25:56 +0300
From: Rhodie
Subject: Bug is sudo?
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).
The normal way to use sudo is 'sudo command' and it asks you for your
password, you put it in and it exec's as root, you get it wrong and it
doesnt.... Try sudo , it says:
sudo.bin: fdsa: command not found
So? you say, well, you can check to see if there is something to play with
that root has hidden....
Take a look at these:
(rhodie@is-so) [~]$ sudo fdsa
sudo.bin: fdsa: command not found
(rhodie@is-so) [~]$ sudo id
Password:
Heh, isn't that purty?
-------------------------------
Get your own rhoide too! Coming soon to stores!
---===***)))The other barefoot wanna-be-programer(((***===---
Find me on almost any major network (exept for efnet, because they suck)
and visit technonet! Dark.TechnoNet.Net 6667
--------------------------------------------------------------------------
------------------------------
Date: Fri, 26 Jun 1998 09:50:30 +0100
From: Andrew Clegg
Subject: Re: guestbook script is still vulnerable under apache
Quoting Lars Eilebrecht (Lars.Eilebrecht@UNIX-AG.ORG):
>
> IMHO the guestbook script should not try to strip out SSIs, but rather
> reject every input which contain the sequence "0804cee5 call 080493c8 SOMETEXT
0804ceea addl $0x4,%esp
0804ceed testl %eax,%eax
0804ceef jne 0804cf9e
0804cef5 pushl %esi
0804cef6 movl 0x8(%ebp),%eax
0804cef9 movl 0x660(%eax),%eax
0804ceff pushl %eax
...
0804eefd leal 0xfffffc00(%ebp),%eax
0804ef03 pushl %eax
0804ef04 pushl $0x8054f08
0804ef09 pushl $0x8054f0b
0804ef0e pushl $0x8054f0e<-- CMDSTR
0804ef13 call 08049368
0804ef18 pushl $0x7f
0804ef1a call 08049768
0804ef1f nop
...
tst.
------------------------------
Date: Thu, 25 Jun 1998 14:35:59 -0400
From: Seth McGann
Subject: Re: security hole in mailx
At 06:19 6/25/98 +0200, you wrote:
[snip]
>Here we go. By the way, although in Linux 2000 "A"s are enough,
>in Solaris you'll need more (10000 worked for me). I've verified
>that Debian GNU/Linux (package mailx-8.1.1-9 and previous) is
>vulnerable. Solaris 5.5.1 and 5.6 (mailx 5.0) also seem vulnerable
>after a couple of quick tests, but I haven't been able to
>check the return address due to lack of a root access to any
>Solaris, so I'm not 100% sure.
[snip]
I assume you cannot retrieve the return address because the core dump
cannot be read by you, since mailx is sgid. There are couple ways around
this. First, copy the mailx binary to your home directory and run it with
the necessary amount of garbage and examine the core dump. Some overflows
will not dump core so you need to use a different technique:
1. gdb mailx
2. run perl -e '.......'
3. Examine the results as the program dies and gdb catches the signal.
Obviously, this wont work with a program that bails before the overflow
because it sees it doesn't have enough privilege.
Another useful technique when examining programs that neither dump core,
and cannot be started from the command line (well, they probably could, but
this way is easier) is the process attachment feature of gdb. Services
started out of inetd can be easily debugged using this method:
1. In terminal 1 start up the service by connecting to it (I prefer
netcat, but whatever).
2. In terminal 2, do a ps to retrieve the pid of the offending service.
3. gdb /path/to/bad/service pidofservice.
4. gdb will break the process on attachment so give it a 'continue' to
keep going.
5. Do the deed in terminal 1.
6. Watch the fireworks in terminal 2, and see exactly what happened.
Since you can only attach to process you own, you'd have to be root to do
this with inetd type services.
On another note, I think it would be a great display of civil disobedience
to continue publishing this list if the WIPO bill is passed.
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: Thu, 25 Jun 1998 12:32:31 -0700
From: Steve Reid
Subject: Re: textcounter.pl (alternate fix)
> The fix I present has the undesirable result that it means the user can
> create files with dangerous file names - the file gets created, and then
> someone comes along and does a "rm *". and that filename with a pipe
> character and evil command executes.
That shouldn't be a problem. Most (all?) shells will escape
metacharacters when expanding wildcards. If it doesn't, it could be
considered a bug in the shell.
What you _do_ have to worry about is filenames that look like options to
rm. If someone creates a file called "-Rf", doing an "rm *" could wipe
out subdirectories.
------------------------------
Date: Fri, 26 Jun 1998 13:22:44 -0700
From: SGI Security Coordinator
Subject: IRIX mailx(1) Buffer Overrun Vulnerability
DISTRIBUTION RESTRICTIONS - NONE - FOR PUBLIC RELEASE
-----BEGIN PGP SIGNED MESSAGE-----
______________________________________________________________________________
Silicon Graphics Inc. Security Advisory
Title: IRIX mailx(1) Buffer Overrun Vulnerability
Number: 19980605-01-A
Date: June 26, 1998
______________________________________________________________________________
Silicon Graphics provides this information freely to the SGI user community
for its consideration, interpretation, implementation and use. Silicon
Graphics recommends that this information be acted upon as soon as possible.
Silicon Graphics provides the information in this Security Advisory on
an "AS-IS" basis only, and disclaims all warranties with respect thereto,
express, implied or otherwise, including, without limitation, any warranty
of merchantability or fitness for a particular purpose. In no event shall
SGI be liable for any loss of profits, loss of business, loss of data or
for any indirect, special, exemplary, incidental or consequential damages
of any kind arising from your use of, failure to use or improper use of
any of the instructions or information in this Security Advisory.
______________________________________________________________________________
- -----------------------
- --- Issue Statement ---
- -----------------------
Silicon Graphics Inc. acknowledges the mailx(1) buffer overrun vulnerability
publically reported by several individuals and in the Internet newsgroups.
Currently, Silicon Graphics Inc. is investigating and no further information
is available for public release at this time.
For the protection of all our customers, SGI does not disclose, discuss
or confirm vulnerabilities until a full investigation has occurred and
any necessary patch(es) are available.
Until Silicon Graphics has more definitive information to provide, customers
are encouraged to assume all security vulnerabilities as exploitable and take
appropriate steps according to local site security policies and requirements.
As further information becomes available, additional advisories will be
issued via the normal SGI security information distribution methods
including the wiretap mailing list.
- -----------------------------------------
- --- SGI Security Information/Contacts ---
- -----------------------------------------
If there are questions about this document, email can be sent to
cse-security-alert@sgi.com.
------oOo------
Silicon Graphics provides security information and patches for
use by the entire SGI community. This information is freely
available to any person needing the information and is available
via anonymous FTP and the Web.
The primary SGI anonymous FTP site for security information and patches
is sgigate.sgi.com (204.94.209.1). Security information and patches
are located under the directories ~ftp/security and ~ftp/patches,
respectively. The Silicon Graphics Security Headquarters Web page is
accessible at the URL http://www.sgi.com/Support/security/security.html .
For issues with the patches on the FTP sites, email can be sent to
cse-security-alert@sgi.com.
For assistance obtaining or working with security patches, please
contact your SGI support provider.
------oOo------
Silicon Graphics provides a free security mailing list service
called wiretap and encourages interested parties to self-subscribe
to receive (via email) all SGI Security Advisories when they are
released. Subscribing to the mailing list can be done via the Web
(http://www.sgi.com/Support/security/wiretap.html) or by sending email
to SGI as outlined below.
% mail wiretap-request@sgi.com
subscribe wiretap
end
^d
In the example above, is the email address that you
wish the mailing list information sent to. The word end must be on a
separate line to indicate the end of the body of the message. The
control-d (^d) is used to indicate to the mail program that you are
finished composing the mail message.
------oOo------
Silicon Graphics provides a comprehensive customer World Wide Web site.
This site is located at http://www.sgi.com/Support/security/security.html.
------oOo------
For reporting *NEW* SGI security issues, email can be sent to
security-alert@sgi.com or contact your SGI support provider. A
support contract is not required for submitting a security report.
______________________________________________________________________________
This information is provided freely to all interested parties and may
be redistributed provided that it is not altered in any way, Silicon
Graphics is appropriately credited and the document retains and
includes its valid PGP signature.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBNZQCGbQ4cFApAP75AQEIZAP/bdnF2xzMPPhFO4RoV2lfzXsLBScMBjCN
bCbYbjh3kyOD7q0vA+wz2y4bDLUEvzB6uWyp++NOuo/RHHHLLxqHusbtCTmn1RhW
NFDXP2nqeFr+FgTJ1E6+ASjH6nWWwTnekp+GzoK/l0kqqSOWGMYcxVtVGTbwocs1
aTo8Z1Epmow=
=KYfO
-----END PGP SIGNATURE-----
------------------------------
Date: Fri, 26 Jun 1998 16:52:41 -0400
From: Douglas Lee Schales
Subject: Re: vulnerability in satan, cops & tiger
In reply to your message dated: Fri, 26 Jun 1998 09:24:17 +0200
>Tiger v2.2.3
>
>the $WORKDIR of tiger 2.2.3 is set to /tmp and many
>temporary files are being written there (it would exeed
>all limits to mention all the lines) ...
>to prevent the raceconditions, $TIGER_HOME/tmp should be created by
>default and $WORKDIR in the config file set to it.
>See below for a patch.
I had seen the patch via the current maintainer of Tiger, and
had told them not to issue it. This is not the best approach
as many people run Tiger off of R/O floppy diskettes, and this
won't work in that situation.
As an interim solution, the user should create a scratch directory
specifically for Tiger, R/W only by root (there is no reason for
anyone else to be able to read the directory). Set WORKDIR to point
to this directory. `/var/spool/tiger' would probably be reasonable.
I've not decided on an "automated" solution that is acceptable,
thus the lack of a patch.
>closing remarks: I was shocked when I found these bugs. These security tools
>have been around since years - and yet nobody had checked this ??
>If this is a reflection of our security consciousness, well, we are in big
>trouble since a long time and things are not getting better (especially with
>M$ around)
Perhaps these tools should have been shuffled up on the priority queue,
because they have "security" associated with them, but it doesn't
really matter. If the "hack" succeeds, it succeeds... does not matter
what the programs purpose in life was...
I also think many believe that we should address the real problem
first, instead of occupying our time dredging through a never ending
source of code. The real problem is the shared `/tmp'.
In my private e-mails, I suggested a (hack) solution, but I've now
decided against it. The correct solution, IMHO, is what I offhandedly
referred to in one message:
rm -rf /tmp
and make the scratch area be private in each accounts home directory
(though some of the shared homes, and roots home being `/' are
problematic). Then we can go through and fix all the apps once and
for all.
Anyhow, off subject...
dls
[ who will now undoubtably now receive a ton of junk mail for his
troubles ]
--
Douglas Lee Schales
------------------------------
Date: Fri, 26 Jun 1998 17:51:14 -0700
From: d
Subject: Re: vulnerability in satan, cops & tiger
> Cops v1.04 (see below for a patch)
[...]
> All the following bugs can be used to create or overwrite any file on the
> system, because these applications run usually under the root id.
There's no reason to run COPS as root; indeed, it explicitly says in
the docs that you shouldn't. Also, the res_diff bug only affects people
running it out of cron (it examines the difference in the last run.)
Checkacct & mail.chk are not used in the normal cops run also. (Shame
on me for doing this anyway, even if it was almost 10 years ago; I used
same-dir temp files for everything else.)
I won't comment on satan, 'cuz wietse already did.
> closing remarks: I was shocked when I found these bugs. These security tools
> have been around since years - and yet nobody had checked this ??
I had found the problems in cops (in res_diff, not the other programs; one
wasn't even mine) but never got around to releasing a patch - hardly an
earth-shattering problem, IMHO.
> If this is a reflection of our security consciousness, well, we are in big
> trouble since a long time and things are not getting better (especially with
> M$ around)
Believe me, the security conciousness of today is light years ahead of
where we where back when, which shows you how pathetic things were then.
However, it's good to see someone putting effort into these things -
keep up the work.
dan
------------------------------
End of BUGTRAQ Digest - 25 Jun 1998 to 26 Jun 1998
**************************************************